Closed mattwthompson closed 1 year ago
Interchange 0.3.10 up-converts 0.3 to 0.4, and also supports processing 0.4 directly. Tests here should be passing using it, and Interchange 0.3.10 should still work with versions of the toolkit that do not include this change.
Thanks!
I didn't investigate the docs issues, but I did start a paper trail: https://github.com/openforcefield/openff-docs/issues/21
I'm in a good mood today and investigating SetupTools changes is the sort of thing that would change that.
Resolves #1678
Cribbed heavily from https://github.com/openforcefield/openff-toolkit/pull/1277/files#diff-fd6b852eaa3bb076240130325c7023d4041de6b0f45bee26c509e61b8a661a23R3839-R3890
There's a dependency loop here in which Interchange needs to parse the new attributes, but can't without the changes to the toolkit - and the toolkit's tests won't pass unless Interchange is updated to handle the new attributes. This mirrors similar issues that might happen in deployment - if (say) 0.14.2 up-converts to 0.4 but for any reason a new version of Interchange isn't immediately released to support it, most of our infrastructure is broken. I'm exploring the possibility of, prior to changes in the toolkit, having Interchange automatically down-convert 0.4 to 0.3 with the intent that a subsequent release does the opposite. Currently these conversions are equivalent in information content so the conversions are not lossy. I think this can enable a smooth transition of all moving pieces, setting the stage for future changes like LJPME, and not breaking existing workflows that rely on OFFXMLs with version 0.3.
vdWHandler.periodic_method
andvdWHandler.nonperiodic_method
nonbonded_resolution_matrix
openff-interchange-base >=0.3.10
to release builds