LPW – Yes. How much backward compatibility are you looking to have?
MT – That’s up to you.
LPW – I’d like to have a lot of backwards compatibility - is 3.8/3.9 reasonable?
MT – I
JW – I think python version reverse compatibiltiy is relatively straightforward (on the big scale). But try/excepts to work with different APIs of upstreams (numpy, openmm, openff) becomes exponentially complex.
LPW – The really memorable upstream breaks were numpy and python 2->3. I wasn’t aware of numpy 2, will take a look. It’s unfortunate that the python ecosystem requires so much maintenance. I think it’s important as the package owner to keep things smooth for users and not have sudden “lurches”.
LPW – I’d love a PR that doesn’t vendor versioneer. In general, there are lots of things that I don’t understand that I could use somewhat pedantic explations of. What does versioneer do?
MT – It does several things, the main one is that it queries git tag to get the current version and adds a + and a hash for post-tag commits. It then interfaces with setuptools to make this version avaialble to packaging tools like pypi and conda.
LPW – What would a solution without versioneer look like?
MT – It’s possible to hard-code the version that’s passed to setup tools, but I don’t recommend it (recently had trouble with an mdtraj release that had a mistake here)
LPW – I think I currently do the manual route for most projects, and there is a bit of toil that I have to go through each time. So when you do this PR, will you switch to the manual mode?
MT – Happy to do it either way.
LPW – Could use advice. I didn’t have trouble with versioneer until python 3.12.
MT – There are updates available for versioneer for 3.12 that lots of people have used, happy to incorporate that too.
LPW – In that case, I’d like PRs that updates to the new versioneer for GeomeTRIC and ForceBalance. There will still be places where I write the version manually too, since that how I’ve been doing it.
MT – I’ll open PRs to update versioneer in these repos.