Support installation with Pydantic v2

[aeisenbarth]

• npe2 version: 0.7.2
• Python version: 3.9.17
• Operating System: GNU/Linux

Description

Pydantic 2 is a rewrite with certain attractive features that developers (may) want to use, but are on hold because npe2 only supports pydantic<2.

• Pydantic 2 embeds Pydantic 1 as from pydantic.v1 import BaseModel. So without changing much of the code, one can add switches that import pydantic if version 1, otherwise pydantic.v1 (if version 2).
• Port npe2 to support Pydantic 2 (see https://docs.pydantic.dev/latest/migration/)

[Czaki]

Did you use npe2 without napari? As much more work need to be done on napari side to support npe2.

[aeisenbarth]

We use Napari 0.4.17, which pulls npe2>=0.5.2 as dependency. When testing Pydantic 2, we got an import error directly from npe2, although considering how much Napari uses Pydantic it probably also needs porting. Interestingly, importing Napari does not immediately raise the error (but later). I found that we were directly importing from npe2.types import LayerData.

[Czaki]

Napari itself has a lazy import mechanism, so import napari should not trigger any exceptions. But we heavily depend on inspecting pydantic objects, so it may take time until a volunteer will spend time updating to pydantic 2.

[jni]

@Czaki well, we can do the strategy suggested by @aeisenbarth, right? Replace every instance of

from pydantic import Foo

with

try:
    from pydantic.v1 import Foo
except ModuleNotFoundError:
    from pydantic import Foo

Where does this fall down?

[aeisenbarth]

I could have a try on doing a pull request for napari and npe2, if this is the decided way to do it.
It seems quite repetetive, there is not by any chance a pattern to define a utility function for this (probably not since import is syntax, not a function)?

[Czaki]

Where does this fall down?

it should not fail if app-model is already ported:

https://github.com/napari/napari/blob/4ba0e6ac3157823e0f2c858832790863223acaec/resources/constraints/constraints_py3.9.txt#L310-L314

[jni]

I also want to point to @tlambert03's pydantic-compat which looks a little bit like what six was for Python 2-3:

https://github.com/tlambert03/pydantic-compat

But using .v1 in a try/except should be sufficient for now. I think pydantic-compat is useful for trying to use whichever pydantic API is available from import pydantic, regardless of version, but it seems to be a bigger lift to port a project to that.

[jni]

This was closed by #321