Pint 0.24 migration

[mattwthompson]

Needs

• Units package update Support Pint 0.24 openff-units#104
• Units package release Release 0.3.0 openff-units#106
• Toolkit change/tests Support Pint 0.24.4 / openff-units 0.3.0 openff-toolkit#1990
• Toolkit release Support Pint 0.24 openff-toolkit#2012
• Test Fragmenter Test against Pint 0.24 branches openff-fragmenter#193
• Interchange change/tests
• Interchange release won't be needed
• Relax openff-units constraint in Interchange feedstock
• Evaluator change/tests Test against openff-units 0.3.0 openff-evaluator#619
• Evaluator release
• BespokeFit change/tests
• BespokeFit release
• NAGL change/tests
• NAGL release

[mattwthompson]

I think that releasing a version of the units package with pint =0.24 or a similar constraint is unlikely to affect production.

Anything that uses the toolkit would need to pull down a very old (~fall 2022) version:

$ micromamba create "pint >=0.24" "openff-toolkit-base" --name foobar | grep openff                                  15:29:07
   - openff-toolkit-base
  + openff-amber-ff-ports         0.0.4  pyhca7485f_0          conda-forge     Cached
  + openff-forcefields        2024.09.0  pyhff2d567_0          conda-forge     Cached
  + openff-toolkit-base          0.11.2  pyhd8ed1ab_1          conda-forge       30MB
  + openff-units                  0.1.8  pyh1a96a4e_0          conda-forge       20kB
  + openff-utilities             0.1.14  pyhd8ed1ab_0          conda-forge     Cached
n

Even going only to 0.12.x is impossible, because of constraints we have in packaging:

$ micromamba create "pint >=0.24" "openff-toolkit-base >=0.12" --name foobar
conda-forge/noarch                                          Using cache
conda-forge/osx-arm64                                       Using cache
nodefaults/osx-arm64                                        Using cache

error    libmamba Could not solve for environment specs
    The following packages are incompatible
    ├─ openff-toolkit-base >=0.12 * is installable with the potential options
    │  ├─ openff-toolkit-base [0.12.0|0.12.1|...|0.16.7] would require
    │  │  └─ openff-units >=0.2.0 * with the potential options
    │  │     ├─ openff-units [0.2.0|0.2.1] would require
    │  │     │  └─ pint [=0.21 *|>=0.20.1,=0.21 *], which can be installed;
    │  │     ├─ openff-units 0.2.2 would require
    │  │     │  └─ pint >=0.21,<=0.23.0 *, which can be installed;
    │  │     └─ openff-units 0.2.0 would require
    │  │        └─ pint >=0.20.1,<0.21 *, which can be installed;
    │  └─ openff-toolkit-base [0.14.4|0.14.5|0.15.0] would require
    │     └─ openff-units >=0.2.1 *, which can be installed (as previously explained);
    └─ pint >=0.24 * is not installable because it conflicts with any installable versions previously reported.
critical libmamba Could not solve for environment specs

Trying something similar with the units package (which is approximately none of the OpenFF stack and a comparatively miniscule portion of the user base):

$ micromamba create "pint >=0.24" "openff-units" --name foobar | grep openff                                         15:29:44
   - openff-units
  + openff-units             0.1.8  pyh1a96a4e_0          conda-forge       20kB
  + openff-utilities        0.1.14  pyhd8ed1ab_0          conda-forge     Cached
n

[mattwthompson]

I thought the units release wouldn't break things, but that was based on my (incorrect) memory of the toolkit's dependency being openff-units =0.2. In fact it's openff-units >=0.2.0, and I did not double-check that particular line in this process.

[mattwthompson]

My attempt at band-aiding (a.k.a. updating constraints to what I thought they were): conda-forge/conda-forge-repodata-patches-feedstock#958