We've had some trouble with python3-pydantic being upgraded and the required version of python3-pydantic-core not being present. This caused 'scarthgap' to ship with a broken version of python3-pydantic. It's still a problem in master because folks are sending upgrades to python3-pydantic when the underlying python3-pydantic-core version requirement is unmet.
In IRC, Ross commented that "python3 -m build" should have caught such unmet version dependency.
So the problem is probably the difference between build depends and runtime depends. -mbuild _should_ be validating build depends in do_compile, but that's a much smaller subset of requirements than you'd expect. In do_install -minstaller doesn't check for dependencies because it's installing into a destdir. However at no point do the *runtime* depends turn into package dependencies. I've been thinking about this in the past and think this could be doable. At do_package time, inject RPROVIDES of the python package name. A not great implementation would simply be RPROVIDES:append = "python-module(${PYPI_PACKAGE})" but a better solution would be to programatically sweep what was installed. Also, scan pyproject.toml and translate the [dependencies] into versioned RDEPENDS with the same python-module(foo) syntax.
Early PoC implementation in: https://git.yoctoproject.org/poky-contrib/log/?h=ross/pypi-deps Which also starts off with a possible fix for the way the sdist tarballs are named on pypi. Since "PEP 625 – Filename of a Source Distribution" https://peps.python.org/pep-0625/ filenames are now normalized. This leaves older sdist tarballs on pypi in the old randomized state however. This has some impact in meta-openembedded as well (about 146 recipes need to be fixed for do_fetch due to the change).
Bulk move to 5.2-M3.
Bulk move to 5.2-M3 and this time I'll actually specify M3!
Related update to the pydeps WIP: https://git.openembedded.org/openembedded-core-contrib/commit/?h=ross/split/pydeps
Bulk move of unassigned 6.0-M* bugs to 6.1-M2.