2024-07-18 LPW/MT/JW meeting note

• LPW – Should have more time over the summer, please ping me repeatedly if I’m leaving you hanging.

• JW – We’re eyeing SBoothroyd’s smee as a primary fitting tool. One of our roadmap goals this year is to do a feasibility study of smee, but we haven’t committed to switching over.

• MT – We’d had a discussion about what maintaining forceblaance looked like - your philosophy was aiming to have things work on release day. Today’s discussion sounds like you’re interested in continuous updates.

  • LPW – I don’t think anything major has changed in the last year. Clarify?

  • JW – Maybe two cases:

  • OpenMM has a breaking update and changes are needed to get FB working with the latest version

  • Keeping FB tested on latest version of python

    • LPW – I think this is important, but it’s not as urgent for me as for you. If there’s a new feature that I want, I’d upgrade somewhat urgently for that. But I don’t strongly impose constraints on my research group or anything. I do agree it’s a problem to not be up to date with python versions. There was a specific case where geometric stopped working with 3.12 because of an issue with versioneer, which is a complex external script. I don’t think there’s anything wrong with FB and 3.12

  • MT – If I submitted a patch that got everything working with 3.12 and didn’t vendor versioneer, is that something you’d be interested in?

    • 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.

    •  

  •  

GeomeTRIC 1.1 release/conda-forge release process

• Plans for 1.1 release?

  • LPW – Lots of new features - incl. NEB, intrinsic reaction coordinates. No major dep changes. Looking at release this summer. Some complications may rise from the two features listed above - Heejune needs to add documentation and testing, and I want to ensure code coverage is over 90%.

  • JW – Feel free to loop us in on technical questions - I don’t know much about the details of the science but would be happy to weigh on technical details.

  • LPW – For release, I usually push a tag to GH, then make a release on pypi, and I’m not sure how the conda package gets made. So maybe we can do a screenshare for that.

  • JW – Feel free to reach out to me for that - Would be happy to screenshare for a release.

• Walk through release process?

• LPW – Current best practices for conda solver? Using mamba?

  • JW + MT – Always use mamba, and to be shiny and new use micromamba

Vsite PR

https://github.com/leeping/forcebalance/pull/292/

JW – I can take over on this

LPW – Great, let me know when it’s ready for review.