Move bioregistry to extras so that OAK is compatible with pydantic v2

[cmungall]

Oh, the wonderful world of python package dependencies. This is the only thing I don't miss about java.

llm uses pydantic2. OntoGPT will use llm and oak. oak uses pydantic1 indirectly via

• linkml-runtime
• bioregistry indirectly via
  • sssom
  • kgcl

We have a rc for linkml (see linkml/linkml#1545)

It looks like there is no plan to move to v2 from bioregistry in the short term biopragmatics/bioregistry#899 (comment)

I think we should be able to move to bioregistry being an extra. For most runtime use cases there is no need for external prefix lookup.

It looks like curies also requires <2:

https://github.com/cthoyt/curies/blob/859362f27bc9aec3f254d0122351341ca65bcab4/setup.cfg#L56

But expand/contract via a dict should be possible to do natively

[matentzn]

What bioregistry functionality does oak need beside curies?

[matentzn]

And why does curies have a pydantic dependency? Maybe configure as "extra"?

[caufieldjh]

curies uses pydantic to define classes for its API but not internally, as far as I can tell. If it's too much of a lift for bioregistry to move to pydantic 2 then maybe curies alone can be compatible with both

[cmungall]

PR for curies here:

• Make explicit cross-version support for Pydantic biopragmatics/curies#64

@matentzn - good point. In fact oak only has indirect dependency on bioregistry, I will update the original comment

[cmungall]

OK, we are good with curies.

We have a problem right now in that it's easy to get into a broken state:

• pydantic > 2
• older version of bioregistry prior to bioregistry pinning pydantic

Until bioregistry is compatible with both, we need to either pin pydantic < 2 or pin bioregistry to a version after bioregistry pinned pydantic

[cmungall]

Fixed