py-pydantic* dependencies

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

there are two packages in pkgsrc which implement "pydantic"
functionality, one layered on top of the other: py-pydantic and
py-pydantic-core.  The latter is implemented in rust, and has this
text in README.md:

   You'll need rust stable [installed](https://rustup.rs/), or rust
   nightly if you want to generate accurate coverage.

"Classic!"  No mention of what "rust stable" or "rust nightly"
actually is in terms of versions, and no mention of when this was
uttered.  So translated, this means "your rust is probably out of
date, please update to whatever is the newest stable version,
irrespective of what you might have from before".  Not very helpful
for a package maintainer who tries to exactly specify dependencies
on tools etc.  But I digress...


Version 2.11.3 (our pkgsrc-current version) of py-pydantic's
pyproject.toml file lists the following dependencies:

dependencies = [
    'typing-extensions>=4.12.2',
    'annotated-types>=0.6.0',
    # Keep this in sync with the version in the `check_pydantic_core_version()` function:
    'pydantic-core==2.33.1',
    'typing-inspection>=0.4.0',
]

You'll probably note the "version of pydantic-core must be exactly
equal to 2.33.1" dependency.

However, if I update to pkgsrc-current for the two packages and
install them both, I get

py312-pydantic-core-2.34.1 Core functionality for pydantic
py312-pydantic-2.11.3 Data validation and settings management using python type hints

which does not satisfy the above quoted dependency specification.

Earlier (before updating pkgsrc & reinstalling), I ended up with

py312-pydantic-core-2.31.1 Core functionality for pydantic
py312-pydantic-2.10.6 Data validation and settings management using python type hints

which apparently do *not* play well together, i.e. I get
"application traceback / exit" with that combination, whereas I do
not with the first pair, even though the dependency specified in
py-pydantic's pyproject.toml isn't adhered to.

Having been around pkgsrc for a while, I get a sense that pkgsrc
likes to always use either "pick any" ("-[0-9]*") or "pick any
version lexicographically larger than X" via (">=X") dependencies.
If the upstream maintainer is not in the habit of introducing
backwards-incompatible changes, that will work, but if that's not
the case, it will not.  As a matter of fact looking for dependencies
in pkgsrc which specify "must use exactly this version" finds
exactly one such file (including pkgsrc-wip), and that one doesn't
even really count:

% find . -name Makefile | xargs egrep 'DEPENDS.*=='
./wip/nanoplot/Makefile:DEPENDS+=       # TODO: pauvre==0.2.0>=0
% 

So...

Skirting the question of "what is the correct way to deal with such
issues?", a more immediate question to answer would be "how should
we deal with this particular issue?"

One suggestion could be to sprinkle comments in py-pydantic and
py-pydantic-core package Makefiles that they need to be updated "as
a unit", preferably so that the "-current" version of both actually
satisfy the py-pydantic package's pyproject.toml dependency
specification, and so that you can't really update py-pydantic-core
without also having a corresponding update of py-pydantic in hand,
ready to go?  For the time being I'm not going to suggest to use a
== specification in a DEPENDS+= line, although that might be more
"correct" seen from the package's perspective, but I suspect this
would create operational issues for users down the line(?)  The
concept "newer is always better" is pretty ingrained in tools such
as "pkgin".

As stated above, the current version of both appears on the face of
it to work together, although that is by no means guaranteed by the
upstream maintainers.

Regards,

- Håvard