Nomdeterministic installations

Posted Jul 18, 2025 22:33 UTC (Fri) by zahlman (guest, #175387)
In reply to: Nomdeterministic installations by SLi
Parent article: Reinventing the Python wheel

> packages can dynamically compute some metadata relevant to the resolving (I forget the exact details). Obviously made worse by not being able to get any of that without downloading the package.

Packages adhering to recent metadata standards get their metadata files extracted automatically and made separately available on PyPI (the relevant standards are described in https://peps.python.org/pep-0658/). But the metadata for a modern source distribution (a `PKG-INFO` file — not pyproject.toml, which you may think of as "source" for the "built" PKG-INFO metadata) is still allowed to declare everything except the metadata version, package name and package version as dynamic. And in older versions of the standard, anything you omit is implicitly dynamic.

There is, now, a hook defined for getting this metadata (https://peps.python.org/pep-0517/#prepare-metadata-for-bu...), but there's nothing to force packages (more realistically, the build systems they depend on) to implement it. By default, the flow is: your installer program builds the entire "wheel" for the package (by setting up any build-system dependencies in an isolated environment, and then running the source package's included build-orchestration code), then checks what metadata is in *that* resulting archive file. (I sort-of touched on this in https://lwn.net/Articles/1020576/ , but without specifically talking about metadata.)

It isn't really supposed to be this way. In principle, https://peps.python.org/pep-0508/ describes a system for making a project's dependencies conditional on the target Python version, OS etc. But apparently this system still can't provide enough information for some packages — and many others are just packaged lazily, or haven't been updated in many years and are packaged according to very outdated standards. And this only helps for dependencies, not for anything else that might be platform specific. (Apparently, *licenses* are platform-specific for some projects out there, if I understood past discussion correctly.)

This is arguably just what you get when you want to support decades of legacy while having people ship projects that mix Python and C (and Fortran, and now Rust, and probably some other things in rare cases).