the "Install latest openff-toolkit" step brought in the right toolkit version, but it was not reflect in the "Conda Environment Information" step. I'm not exactly sure why, maybe some conda vs. mamba thing or a something not set right in the shell.

Ugh thanks for catching that! I've found that conda and mamba act differently when installing stuff and it is super annoying. I'm going to get the OE license working again in this repo which will speed tests up quite a bit, thanks for your help on this @mattwthompson

Well it's an improvement over my previous idea of "trust me, no need to write tests" !

This might take me a few days of iterations to finish - handling both APIs will be larger in scope than I originally thought but I don't think significantly trickier.

@mikemhenry I'm seeing some errors that don't match up with the code I've changed, like here: https://github.com/openmm/openmmforcefields/runs/7777051481?check_suite_focus=true#step:7:2424

        # Generate atom types
        atom_types = etree.SubElement(root, "AtomTypes")
        for particle_index, particle in enumerate(molecule.particles):
            # Create a new atom type for each atom in the molecule
            paricle_indices = [particle_index]
            atom_type = etree.SubElement(atom_types, "Type", name=particle.typename,
>               element=particle.element.symbol, mass=as_attrib(particle.element.mass))
E           AttributeError: 'Atom' object has no attribute 'element'

../../../micromamba-root/envs/openmmforcefields-test/lib/python3.8/site-packages/openmmforcefields/generators/template_generators.py:966: AttributeError

which does not match up with my diff: https://github.com/openmm/openmmforcefields/pull/225/files#diff-8bf8dcfa6a7e99dc62374cfe0a1efab5c2e7b0f22fa1e86111b7fff3f71ced84R970-R972

        for particle_index, particle in enumerate(molecule.particles):
            # Create a new atom type for each atom in the molecule
            paricle_indices = [particle_index]
+            element_symbol = particle.element.symbol if uses_old_api else particle.symbol
            atom_type = etree.SubElement(atom_types, "Type", name=particle.typename,
-                element=particle.element.symbol, mass=as_attrib(particle.element.mass))
+                element=element_symbol, mass=as_attrib(particle.element.mass))

I don't think this would result of python setup.py install over python setup.py develop but that's the most obvious culprit. Any suggestions where to start looking?

I know that we can't use pip install -e . from this PR #124

I added some debugging to check to see if somehow we installed the package from some circular dependency, since I don't know how else the source wouldn't match the PR.

The dependency loop is because of Espaloma:

$ conda activate openmmforcefields-test && mamba repoquery whoneeds openmmforcefields

                  __    __    __    __
                 /  \  /  \  /  \  /  \
                /    \/    \/    \/    \
███████████████/  /██/  /██/  /██/  /████████████████████████
              /  / \   / \   / \   / \  \____
             /  /   \_/   \_/   \_/   \    o \__,
            / _/                       \_____/  `
            |/
        ███╗   ███╗ █████╗ ███╗   ███╗██████╗  █████╗
        ████╗ ████║██╔══██╗████╗ ████║██╔══██╗██╔══██╗
        ██╔████╔██║███████║██╔████╔██║██████╔╝███████║
        ██║╚██╔╝██║██╔══██║██║╚██╔╝██║██╔══██╗██╔══██║
        ██║ ╚═╝ ██║██║  ██║██║ ╚═╝ ██║██████╔╝██║  ██║
        ╚═╝     ╚═╝╚═╝  ╚═╝╚═╝     ╚═╝╚═════╝ ╚═╝  ╚═╝

        mamba (0.22.1) supported by @QuantStack

        GitHub:  https://github.com/mamba-org/mamba
        Twitter: https://twitter.com/QuantStack

█████████████████████████████████████████████████████████████


Executing the query openmmforcefields



 Name     Version Build        Depends           Channel
─────────────────────────────────────────────────────────────
 espaloma 0.2.3   pyhd8ed1ab_0 openmmforcefields conda-forge

@mattwthompson I will get that dependency fixed on conda-forge soon ™️

@mattwthompson false alarm, openmmforcefields doesn't pull in espaloma, but we want to install espaloma since it provides support for ML ff and works with openmmforcefields. So we need to install it, but we just need to uninstall openmmforcefields before we install openmmforcefields from source, is it okay if I do these fixes on this PR?

is it okay if I do these fixes on this PR?

Please feel free!

IIUC, espaloma is needed for tests here (totally reasonable) and its conda package pulls in (the latest conda build of) openmmforcefields? If so, I'd think a conda remove --force openmmforcefields would do the trick. I've always thought installing a local build overwrites whatever's in the environment, so I'm confused how this is an issue in the first place. I could be wrong in my assumption or there could be some nuance with how stuff is set up here. Not sure

I've always thought installing a local build overwrites whatever's in the environment, so I'm confused how this is an issue in the first place.

It does, but my hunch (this is after a glass of scotch) is that the way we are installing the package with python setup.py install doesn't overwrite it correctly.

I did check and https://github.com/conda-forge/openmmforcefields-feedstock/blob/main/recipe/meta.yaml doesn't pull in espaloma

So I agree, for whatever reason we just need to make sure we uninstall openmmforcefields before we install it from source

Oh I think CI is going to fail since this is done on a fork and github wants to protect the secrets?

I'll try moving this to a branch

Thanks! I probably won't get to this until tomorrow so feel free to do whatever you need to

Working on this in #227 instead