FileNotFoundError: '[...]/data/defaults.txt/constants.txt'

[j-wags]

We've become aware of an issue with the caching system that we've started using in Pint, which manifests as an error message like FileNotFoundError: [Errno 2] No such file or directory: '[...]/data/defaults.txt/constants.txt'. See https://github.com/orgs/openforcefield/discussions/41 for our recommended solution.

[epretti]

Just looked into this for a few minutes after it was mentioned and I was thinking about it again. I think I can reproduce it in a reliable way. Delete any existing Pint cache files per the linked solution. Create a conda environment and do something in it that causes the cache to get generated.

conda create -y -n openff-pint-test-1 openff-toolkit
conda activate openff-pint-test-1
python -c "import openff.toolkit; openff.toolkit.Molecule()"

The resulting cache files point to absolute paths to openff/units/data/[defaults,constants].txt inside of the conda environment (open up the .json files that get created in the cache directory). Delete the environment:

conda deactivate
conda env remove -y -n openff-pint-test-1

Make a new one with a different name and try the same thing:

conda create -y -n openff-pint-test-2 openff-toolkit
conda activate openff-pint-test-2
python -c "import openff.toolkit; openff.toolkit.Molecule()"

It finds the cache pointing to files in the old environment that doesn't exist anymore. Presumably a pint bug because ideally it should discard and regenerate the cache if the file is gone, unless OpenFF is invoking it in a non-standard way? I didn't dig further but wanted to check since I made a comment about it feeling like a Pint bug and wanted to be more concrete.

[mattwthompson]

openff-units 0.3.1, which I am to release next week, ought to mitigate this by not using any cache

I have some ideas about where this might originate, but they are moot as long as we are reverting that feature altogether

[mattwthompson]

openff-units 0.3.1 is now live and, by nature of not caching the unit registry at all, should mitigate this issue.

Please let us know if that is not the case!