General updates | MT – Met with Zach earlier, I like his attitude. Should he be in more slack channels? JW – OFFTK 0.14.1 out, finishing ChemicalEnvironment removal, adding custom polymer loader (for examples see here). Will continue on to QCSubmit/QCA interface now. JW – Thanks for pushing SMIRNOFF EP through. I like the PR to implement. MT – One complication with implementation, I think I’ve worked around the relevant cases. When we did this a year ago with the electrostatic method there was an inherent simplicity with the implementation, since the file loading and OMM Force creation happened in the same file (there was never a case where create_force had to check to see whether the Toolkit knew about a certain version of a ParameterHandler tag.) So Interchange needs to know which version of the file was read… OFFTK could be made to auto-upgrade to vdW 0.4, but this would immediately require anew release of Interchange. So the vanilla approach will be to do simultaneous releases. But that will be high-risk. So what I’d rather do is have OFFTK upconvert to 0.4, and then Interchange would inspect the OFFTK object and DOWNconvert to 0.3 So the process would be: Release of IC that accepts 0.3 AND 0.4 version vdWHandlers (downconverting 0.4s to 0.3s) Release of OFFTK that auto-upconverts all 0.3s to 0.4s Release of IC to accept 0.3s and 0.4s directly.
JW – This plan makes sense, though I’d also be fine with simultaneous releases. MT – The simultaneous release plan will make a hard discontinuity in package support, whereas the three-step release plan will offer some flexibility for different versions. JW – Good point - Let’s do the 3 step plan then. MT – Ok, I think the PRs are nearly ready to go, I’ll loop you in on release planning.
JW – Advice on pydantic 2? Should we stick with the legacy v1 API in v2 or just keep pinning to v1? MT – I have a plan on this - Our previous plan was to pin everything to v1 and greenlight each component in our ecosystem to v2 until it’s all done. I was previously unaware of the legacy API in v2 - Early testing looks promising and there’s a pattern I can roll out to get this going throughout our ecosystem. MT – Two particularly good things here: A try/except import trick with the legacy api will make it compatible with pydantic v1 or v2. The code changes to get the backdoor working are pretty minimal - Will just need to roll them out in a lot of python files.
Two downsides are: Have to make this change in ALL software that uses pydantic, and release each package. We have a lot of interdependent repos, so that will mean making releases in a careful and specific order. (models - interchange - toolkit (implicitly) - bespokefit - fragmenter - qcsubmit) This just punts on actually updating the code. And pydantic v2 does have some conceptual differences so this will require a lot of hand-holding.
MT – My plan is basically to test this whole move using off-label builds. I think I can get help on testing this by sharing a conda yaml that pulls from these labels with our downstreams. MT – I’m comfortable taking responsibility for this top-to-bottom, will probably take a few weeks. I’ll reach out if any toolkit releases are needed but I doubt it. May need releases of bespokefit, fragmenter, qcsubmit. JW – That sounds great.
Â
|