Decide on timeline for dropping Pydantic 2

[cthoyt]

Pydantic v2 has been out for more than a year, and it's time to decide on a timeline for dropping cross-compatibility with Pydantic v1.

We have to do this because the amounts of deprecations and warnings are a big risk for the code staying up to date in the future, and it's not economical to keep so much legacy code around.

The carrot is that the Pydantic v2 API enables a lot of interesting things for annotating models, and APIs with FastAPI (see the https://github.com/cthoyt/semantic-pydantic experiment).

I posted on the OBO slack a few months back and basically nobody had any complaints, except for https://github.com/gyorilab/mira which was on Pydantic v1 only. It now appears to be compatible with Pydantic v2 as of gyorilab/mira#360.

I think that switching over at the beginning of 2025 is a reasonable timeline. Any alternate suggestions?

[bgyori]

Yes, we migrated MIRA to Pydantic v2 (it turned out to be a lot of work but it's done now) so that is not an issue anymore. More generally, there are many Python packages that use bioregistry as a dependency and it's hard to assess the downstream effect systematically. Two remarks related to this:

• Many GitHub repos have a useful list of dependent packages listed at e.g., https://github.com/gyorilab/gilda/network/dependents but for some reason this is empty for Bioregistry: https://github.com/biopragmatics/bioregistry/network/dependents. I briefly looked into this over the summer and found e.g., https://github.com/orgs/community/discussions/34687 where the accepted answer actually suggests opening up a support ticket with GitHub if the dependents are not appearing correctly - I haven't done this yet.
• As an alternative, there is some useful information from keyword searches on GitHub for repositories referencing the bioregistry (https://github.com/search?q=bioregistry&type=code) or co-occurrence of bioregistry and pydantic (https://github.com/search?q=bioregistry+pydantic&type=code). Just spot checking reveals some cases where problems could arise e.g. https://github.com/HUBioDataLab/CROssBARv2/blob/main/poetry.lock.

Generally, my view is that in a package that is likely one of many dependencies of downstream packages, it's better to err on the side of broad compatibility to avoid (as in the case Pydantic v1->v2) potentially time consuming migration. But I don't have a very strong feeling about it.

[bgyori]

Fwiw I submitted an inquiry to GitHub support and they did something on the back-end that fixed the dependents page: https://github.com/biopragmatics/bioregistry/network/dependents. This is a really interesting view of who uses the Bioregistry!