mypy plugin working incorrectly for exported v1 module

[JaimeLennox]

Initial Checks

• I confirm that I'm using Pydantic V2

Description

Hello! We're beginning our migration to pydantic v2, and as a first step we thought we'd simply upgrade the version and use the exported v1 module simply by changing import pydantic to import pydantic.v1 in our imports.

This works fine for the most part, but the mypy plugin doesn't seem to work anymore (note that we switched our mypy configuration to use plugins = "pydantic.v1.mypy").

This is most obvious with the v1 BaseSettings class, where we load atrributes from a .env file.

For the example code below, running with pydantic v1 produces no errors, but pydantic v2 with the v1 mypy plugin shows:

test.py:11: error: Missing named argument "foo" for "Settings"  [call-arg]

I think this is probably because in the v1 mypy plugin, the fullname constants aren't using the v1 module?
E.g.

BASEMODEL_FULLNAME = 'pydantic.main.BaseModel'

should probably be

BASEMODEL_FULLNAME = 'pydantic.v1.main.BaseModel'

?

Example Code

from pydantic.v1 import BaseSettings


class Settings(BaseSettings):
    foo: str

    class Config:
        env_file = ".env"


settings = Settings()

Python, Pydantic & OS Version

pydantic version: 2.0.3
pydantic-core version: 2.3.0 release build profile
install path: /Users/test/.virtualenvs/venv/lib/python3.11/site-packages/pydantic
python version: 3.11.0 (main, Nov  1 2022, 09:15:56) [Clang 13.1.6 (clang-1316.0.21.2.5)]
platform: macOS-13.4.1-arm64-arm-64bit
optional deps. installed: ['email-validator', 'typing-extensions']

Selected Assignee: @dmontagu

[dmontagu]

Great catch!

@hramezani were you the one that set up the copying of the v1 code into the module? (Can't remember who it was..) Any ideas how to deal with this? Should we just manually edit it? It feels like that might be error prone in future releases...

I guess we could write a v2 test that checks that the value is set properly in that module, so that we don't forget to fix it back up after re-updating the code.

[dmontagu]

@JaimeLennox could you check whether the branch in #6921 fixes this issue for you?

And if there are any other issues you can see how to fix, feel free to comment them on that PR.

[JaimeLennox]

Yep, I can confirm with that branch it now works as expected - thanks for fixing!

The only thing I'll mention is that there's now a user warning when mypy runs, which is a little strange given it comes from pydantic code itself, but I don't think it's a big deal given that users would be migrating away from the v1 plugin anyway:

mypy .
/Users/test/.virtualenvs/venv/lib/python3.11/site-packages/pydantic/_migration.py:283: UserWarning: `pydantic.utils:is_valid_field` has been removed. We are importing from `pydantic.v1.utils:is_valid_field` instead.See the migration guide for more details: https://docs.pydantic.dev/latest/migration/
Success: no issues found in 1 source file

[dmontagu]

@JaimeLennox we merged the relevant PRs into the 1.10.X-fixes and main branches. If you want that warning suppressed, feel free to open a couple new PRs (one per branch) to do so; I would suggest modifying the mypy plugin file to do something like:

with warnings.catch_warnings():
    warnings.filterwarnings("ignore",category=UserWarning)
    from pydantic.utils import ...  # whatever the warning-generating import is

The main reason not to do this is that it might make it a bit more likely that people use this approach up until the point where it actually breaks and have no warning about it. Given that, I'm not inclined to open the PR myself, but if you care enough to do so I would be inclined to merge it. Up to you.