Updating to Pydantic V2

[glass-ships]

Koza will need this looked at as well, along with the following:

monarch-app/backend (similarity)
><glass@rocinante> poetry show pydantic
 name         : pydantic                                                        
 version      : 1.10.12                                                         
 description  : Data validation and settings management using python type hints 

dependencies
 - typing-extensions >=4.2.0

required by
 - bioregistry <2.0
 - curies <2.0
 - fastapi >=1.6.2,<1.7 || >1.7,<1.7.1 || >1.7.1,<1.7.2 || >1.7.2,<1.7.3 || >1.7.3,<1.8 || >1.8,<1.8.1 || >1.8.1,<2.0.0
 - linkml *
 - linkml-runtime >=1.10.2,<2.0.0

[glass-ships]

https://docs.pydantic.dev/2.1/migration/

[glass-ships]

See linkml/linkml#1575

[cthoyt]

FYI bioregistry and CURIEs both now support pydantic 1/2

[glass-ships]

Nice, so close!!

It looks like oaklib still indirectly depends on prefixmaps < 0.2, so once that gets updated I can move this forward!

Because no versions of oaklib match >0.5.22
 and oaklib (0.5.22) depends on kgcl-schema (0.6.0), oaklib (>=0.5.22) requires kgcl-schema (0.6.0).
And because kgcl-schema (0.6.0) depends on prefixmaps (>=0.1.5,<0.2.0), oaklib (>=0.5.22) requires prefixmaps (>=0.1.5,<0.2.0).
So, because monarch-py depends on both oaklib (>=0.5.22) and prefixmaps (^0.2), version solving failed.

[cthoyt]

We just fixed the kgcl-schema issue ten minutes ago

[cthoyt]

try again and hopefully it works 🚀

[glass-ships]

slightly delayed, but yes that worked - i'm able to upgrade pydantic to 2.5 here now!
thanks so much for your help!

[glass-ships]

@amc-corey-cox i hear you learned a better way to get our prefixmap, could I ask you to enlighten me?
I think updating that here would allow us to bring this in

[amc-corey-cox]

Sure, here is my notebook on this:
https://colab.research.google.com/drive/155XsHrhtrV85PjuAZ9ds9U3XHriG3_cF#scrollTo=__ctJM_dA7Ts
The salient feature is this:

from prefixmaps.io.parser import load_context
merged_context = load_context("merged")
merged_converter = merged_context.as_converter()

That will give you the converter from the merged context. I've also created a new context of merged.monarch that we should start using going forward but it is just merged and I don't think we should target that for the current release milestone.

You would use it the same way:

from prefixmaps.io.parser import load_context
merged_monarch_context = load_context("merged.monarch")
merged_monarch_converter = merged_context.as_converter()