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

Add pydantic.v1 namespace to Pydantic v1 #9042

Merged
merged 4 commits into from
Mar 25, 2024

Conversation

exs-dmiketa
Copy link

@exs-dmiketa exs-dmiketa commented Mar 18, 2024

Change Summary

Following jenshnielsen's brilliant idea in #6022, I added a pydantic.v1 alias to the v1 version of Pydantic. This will enable cross-version Pydantic support and easier migration of expansive v1 codebases by switching all pydantic imports to pydantic.v1 and removing the upper bound.

Fix #6022

Checklist

  • The pull request title is a good summary of the changes - it will be used in the changelog
  • Unit tests for the changes exist
  • Tests pass on CI
  • Documentation reflects the changes where applicable
  • My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @hramezani

skip change file check

@exs-dmiketa
Copy link
Author

This is my first Pydantic PR so sincere apologies if I'm doing this wrong!

I added a very simple test to capture the main functionality.

Crucially, the following will not work: from pydantic.v1.dataclasses import dataclass. But from pydantic.v1 import dataclasses will. We could try to fool the submodule detection in at least two ways:

  1. Copy entire files into a v1 subfolder. (Not massively different from the "v1 in v2" setup.)
  2. Put dummy files into a v1 subfolder, e.g. v1/dataclasses.py, and only reimport the top-level corresponding file (from ..dataclasses import *)

Given that this would be merely a transitional solution to help users move from v1 to v2, I'm not sure the issue is critical, but happy to defer to maintainers. Please review. :)

Copy link
Member

@sydney-runkle sydney-runkle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@exs-dmiketa,

Great, thanks! We'll release this change with an upcoming V1 patch (probably next week).

tests/test_v1.py Outdated Show resolved Hide resolved
tests/test_v1.py Outdated Show resolved Hide resolved
@sydney-runkle sydney-runkle enabled auto-merge (squash) March 25, 2024 21:32
@sydney-runkle sydney-runkle merged commit aa98b58 into pydantic:1.10.X-fixes Mar 25, 2024
48 checks passed
@exs-dwoodward
Copy link
Contributor

Hi all, this change is useful for things being imported directly like:

from pydantic import ...

but for imports like:

from pydantic.fields import ModelField
from pydantic.generics import GenericModel

or:

from pydantic import fields
from pydantic import generics

it doesn't translate as well. @sydney-runkle would a PR that adds the ability to do these kinds of imports from the v1.py module be useful? IIUC that would make v1 --> v2 migration (with the same existing v1 types / models of course) simply turn into a find + replace of from pydantic --> from pydantic.v1 in all cases. I have a branch locally with this and am happy to contribute a PR if you think it would be useful!

rytilahti added a commit to python-kasa/python-kasa that referenced this pull request May 1, 2024
With pydantic/pydantic#9042 being shipped with
[1.10.15](https://docs.pydantic.dev/latest/changelog/#v11015-2024-04-03),
we can clean up the imports a bit until we make decisions how to move
onward with or without pydantic.

---------

Co-authored-by: Steven B. <51370195+sdb9696@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants