Replace setup.py with pyproject.toml, update actions to latest versions

[chrisjonesBSU]

PR Summary:

Same as the PR made over in mBuild mosdef-hub/mbuild#1217

It's recommended to use pyproject.toml instead of setup.py and gets rid of the deprecation error when running pip install . inside the repo.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.85%. Comparing base (c8c62ae) to head (6459585).
Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #865      +/-   ##
==========================================
- Coverage   94.07%   89.85%   -4.23%     
==========================================
  Files          65       65              
  Lines        6953     6976      +23     
==========================================
- Hits         6541     6268     -273     
- Misses        412      708     +296     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chrisjonesBSU]

The failing bleeding edge test is related to this issue. Haven't had a chance to take a look yet.

[CalCraven]

This looks ready to merge.

[chrisjonesBSU]

I can't re-create the bleeding edge test errors locally. It seems like an issue with lark. After all the updates to the environment from other .yml files, I wonder if the lark version is an older one.

      def __init__(self, optional_names=""):
          if optional_names:
              for n in optional_names:
                  if not n.startswith("_"):
                      raise FoyerError(
                          "Non-element types must start with an underscore, you passed {}".format(
                              ", ".join(optional_names)
                          )
                      )
      
              optional_names = sorted(optional_names, reverse=True)
              self.grammar = GRAMMAR.format(
                  optional="{}|".format("|".join(optional_names))
              )
      
          else:
              self.grammar = GRAMMAR.format(optional="")
  >       self.PARSER = lark.Lark(self.grammar, parser="lalr")
  E       AttributeError: module 'lark' has no attribute 'Lark'

[chrisjonesBSU]

Ok, the environment has lark 1.2.2, but still gets this attribute error.

With lark 1.2.2, I don't get an attribute error

>>> import lark
>>> lark.__version__
'1.2.2'
>>> lark.Lark
<class 'lark.lark.Lark'>

[CalCraven]

This looks wrong in line 52 under the Bleeding Edge Stage (Check Environment)
focefield_utilities 0.3.0+12.ga23b12a pypi_0 pypi
Just wanted to point that out.

We also are getting lark 1.2.2, but wonder if the issues lies in this odd downgrade of mBuild and Foyer, then reinstalling from source. Essentially, since the packages depend on each other, installing the dependencies of each may cause some self-reference issue. There's some reference to some weird "already existing files" happening during the linking step

[chrisjonesBSU]

Yeah, I noticed the bleeding edge test isn't using the latest version of mBuild. I wonder if we should have yet another .yml file for running bleeding edge tests? That way, it installs everything in one go. We can install mbuild, foyer and forcefield_utitilities via pip in the yml file. This might be a more manageable and accurate way to do bleeding edge tests rather than running mamba update 3 different times.

[chrisjonesBSU]

Yeah, I noticed the bleeding edge test isn't using the latest version of mBuild. I wonder if we should have yet another .yml file for running bleeding edge tests? That way, it installs everything in one go. We can install mbuild, foyer and forcefield_utitilities via pip in the yml file. This might be a more manageable and accurate way to do bleeding edge tests rather than running mamba update 3 different times.

I added this out of curiosity, we can still talk about it and switch it back if we decide not to go this route.

[CalCraven]

Looks like it's working as expected now. I'd say in general this is better practice since it will decrease confusion when the environments get updated.

[CalCraven]

Current bleeding edge test gets Foyer 1.0.0, mBuild 1.0.0, and GMSO 0.0.0.

Looks good, other than the pip install for GMSO now is naming the wheel with the wrong version.

[chrisjonesBSU]

Looks like it's working as expected now. I'd say in general this is better practice since it will decrease confusion when the environments get updated.

Agreed. Should we have a new .yml file for this, as it is now, or should this new one become environment-dev.yml? This is basically a mosdef dev environment, rather than GMSO specific one. Whatever we decide, I'll make the same change in current mbuild PR, then in foyer in a new PR.

[CalCraven]

I think your point is reasonable, this can essentially be a single dev environment. If you're going to be developing the packages, there aren't that many extra dependencies across all of them.

[chrisjonesBSU]

Current bleeding edge test gets Foyer 1.0.0, mBuild 1.0.0, and GMSO 0.0.0.

Looks good, other than the pip install for GMSO now is naming the wheel with the wrong version.

This should be fixed now.

[chrisjonesBSU]

Ok, so just to clarify, gmso, foyer and mbuild will essentially all have the same environment-dev.yml file, but each one will install the other 2 packages from source instead of from conda. This file can be used to run bleeding edge tests instead of cloning, updating, and installing from source in the CI.yaml workflows for each repoi.

[CalCraven]

I'm still confused as to what this package is. It looks like a typo somewhere for forcefield_utilities.
https://github.com/mosdef-hub/gmso/actions/runs/12920432658/job/36032738911?pr=865#step:5:69

[CalCraven]

Found the culprit.

[chrisjonesBSU]

Found the culprit.

I'll make a PR to fix that. I need to update the versioning in the .toml file over there as well.