Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support Pydantic 2+ or drop pydantic #1075

Open
gdementen opened this issue Sep 13, 2023 · 1 comment
Open

support Pydantic 2+ or drop pydantic #1075

gdementen opened this issue Sep 13, 2023 · 1 comment

Comments

@gdementen
Copy link
Contributor

Pydantic2 has been released in june 2023 and it is a massive change compared to v1. There is even a whole migration guide at:
https://docs.pydantic.dev/2.0/migration/

Needless to say, larray is not compatible with it. We should either rewrite Checked* using v2, or stop using Pydantic at all (I have some proof of concept code doing this somewhere).

PS: CI is not failing on this (yet) because anaconda packages for Pydantic are still at v1. But I noticed the error via readthedocs where pydantic is installed via pip instead.

@gdementen gdementen added this to the 0.35 milestone Sep 13, 2023
gdementen added a commit to gdementen/larray that referenced this issue Sep 14, 2023
This is a workaround until we add proper support for v2 (see larray-project#1075)
gdementen added a commit that referenced this issue Sep 14, 2023
This is a workaround until we add proper support for v2 (see #1075)
@gdementen
Copy link
Contributor Author

FWIW, here are the pro and cons of pydantic (v2) vs our own solution:

Pros:

  • more standard
  • probably easier to evolve more features (range checking and stuff like that).
  • maybe there is hope of having someday the axes validated statically (by PyCharm/mypy/...) in addition to at runtime
  • probably faster (due to v2 using a rust runtime), but that needs to be checked as v1 is much slower than our custom solution. Speed is irrelevant (fast enough) either way in our typical uses cases though.

Cons:

  • For our current required feature set, using Pydantic is more complex than an homegrown solution AFAICT
  • Using an external solution involves more risk of having to adapt again in the future
  • One more dependency to track

I would say that, in the end, if we only ever want to support the current feature-set with only runtime checking of axes, a custom solution would be less (maintenance) work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant