fix: relax constraint on pydantic

[bernardcooke53]

This change allows DSI to be installed in environments alongside either pydantic v1 or v2

Resolves Doesn't resolve #134, but does make it less impactful to end users

Description

Pydantic retained the v1 codebase in a v1 namespace when upgrading to v2, per their Migration Guide. Therefore it's possible to make minimal code changes while allowing DSI to co-exist alongside either Pydantic v1 or v2.

According to the discussion on #217, this is an issue that might take some time to puzzle through fully given the need to support both Pydantic v1 and v2. This PR would alleviate the constraint on Pydantic without requiring additional testing or impact on end-users, so hopefully also relieves some pressure on the maintainers with regards to timescales. It might (I haven't checked for certain) enable a more gradual upgrade path, module-by-module.

The downside being that I've excluded pydantic from mypy checking for missing imports - I can change the code so that it isn't globally ignored, but I figured this would be an issue everywhere.
I completely understand if this gets closed as "not the right approach" - just thought I'd add what I can to help 🙂

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• This PR includes tests, or tests are not required/relevant for this PR
• I have run changie new to create a changelog entry

[esciara]

Thanks for trying out !

Carefull though: there are a lot of behavioural changes from pydantic v1 to v2. Notably around required optional and nullable fields. Wonder whether at the very least this should be applied...

Do these test pass with pydantic v2 as dependency?

[bernardcooke53]

Hey @esciara - the tests do pass with pydantic v2 (you can adjust locally to pin to Pydantic >= 2.0.0 and still tests passing). I'm not sure how I could ensure the tests pass with both versions of Pydantic in CI but absolutely open to suggestions!

The behaviour changes are tricky, absolutely, so this PR just uses the pydantic.v1 namespace, which was added as part of the update to v2, to access the old objects if Pydantic v2 is installed. This way, even with Pydantic v2 there should be no behaviour change in the objects we're importing. The link you have provided relates to the difference in behaviour you'd see when using Pydantic v2 and, for example, pydantic.BaseModel (v2 object) vs pydantic.v1.BaseModel (v1 object).

[bernardcooke53]

Oh - I should also add - because we always try to import from pydantic.v1 first, we'll get the v1 objects, even if v2 is installed. Because we're catching ModuleNotFoundError instead of AttributeError there shouldn't be a risk that a typo (e.g. from pydantic.v1 import spam) will result in accidentally trying to import that object from pydantic due to the try-except

[bernardcooke53]

Think I'll close this as #238 supersedes it, and is cleaner too 😅