Test new openff-models w/ pydantic v2

[IAlibay]

No description provided.

[mikemhenry]

I am sure that pip check is exposing a real error, but for the sake of testing this I would comment it out.

[IAlibay]

Known errors:

1. openff.units needs Kelvin = kelvin
2. some issue with comparing frozen vs unfrozen comparison

[IAlibay]

Some thing about GUFE key stability

[IAlibay]

Calling schema_json is also failing.

[pep8speaks]

Hello @IAlibay! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file gufe/tests/test_models.py:

Line 19:1: E265 block comment should start with '# '
Line 45:5: E265 block comment should start with '# '
Line 104:9: E265 block comment should start with '# '
Line 105:9: E265 block comment should start with '# '
Line 109:9: E265 block comment should start with '# '
Line 112:9: E265 block comment should start with '# '
Line 112:9: E303 too many blank lines (2)

Comment last updated at 2024-08-27 11:43:27 UTC

[mattwthompson]

Any other of these classes you'd like? For example, I'm probably adding _ElementaryChargeQuantity https://github.com/openforcefield/openff-interchange/pull/1066/files#diff-e701185426285c406ac35c83d090e6784f044d92574a9f9527078b20f122f649R158-R164

[mattwthompson]

^ can still add whatever classes, or more usefully document how to generate them downstream

Currently I'm planning to roll with these changes being in Interchange, not a release of openff-models

[IAlibay]

Currently I'm planning to roll with these changes being in Interchange, not a release of openff-models

@mattwthompson can you maybe provide a bit more detail on what you mean by this? I.e. is openff-models not being updated anymore or do you mean the addition of these extra classes are only happening in Interchange?

openff-models going away completely is going to be.. a bit of an issue for us, we definitely can't have gufe depend on a big dependency like Interchange.

[mattwthompson]

Interchange 0.4.0 doesn't depend on openff-models, it just has the relevant bits ported over into one or two files since the functionality is pretty small in scope. It can be accessed with openff-interchange-base which is pretty lightweight or just ported over here.

[IAlibay]

Question from today's alchemiscale: should the default strategy be that we vendor openff-models? I.e. is openff-models going to update again or should we go with what's in interchange?

cc @mattwthompson

[mattwthompson]

Let me try vendoring it here to see if it's as easy as I suspect. Should I work off of this branch or a different reference?

[IAlibay]

Let me try vendoring it here to see if it's as easy as I suspect. Should I work off of this branch or a different reference?

I think for now I would say "don't put any extra work on this" - if we can work out what OpenFF's intended future is, then we can explore the idea of "should we vendor".

Read: "I don't want to create any extra work for anyone".

[mattwthompson]

I don't have plans to make a new release of openff-models and I don't think anything else in OpenFF needs the update; the functionality we need is now in openff/interchange/_annotations.py and possibly a few other locations.

The relevant files are probably around these parts:

• https://github.com/openforcefield/openff-models/blob/bbc241643a722d03b70b0d0b9d24f4d0642a6d89/openff/models/models.py
• https://github.com/openforcefield/openff-models/tree/pydantic-2-redo/openff/models/types

Some complexity can be stripped out if unyt and/or openmm.unit support isn't needed, and I think a couple of "deprecated" features might still be used.

[mattwthompson]

Of course, you could also just try not updating at all and see what happens

[IAlibay]

Thanks @mattwthompson - @dotsdl did you want to discuss this further? We probably should work out a) if we need to implement the changes, and b) how we go about it.

[dotsdl]

We decided that we will proceed with vendoring the components relevant to gufe from openff-models and go from there. I've created this issue for that activity: #397

I think we can close this PR; thank you @mattwthompson for your help with this!