Pip doesn't aim to manage packages in the first place, however; expecting to lock the entire environment is out of its wheelhouse (or should I say .whl-house?).

For Paper, rather than implementing anything like Pip's "dry-run" option (which is nowhere near as "dry" as you'd expect, but that's a separate issue...), I'm planning to have a separate command to output PEP 751 lockfiles representing an individual resolution, i.e. the packages that would be added to the environment.

It may be this new lock file acts as an interchange format, that all tools can consume or produce, but not something they internally use.

Though, maybe we're lucky and tools will be able to use it directly, or we might have to wait for a new version of the standard once tools have been able to work with it long enough to know the deficiencies.

Non-lock files, like pyroject.toml and requirements.in remain unaffected.

Tools that use custom lock files are at liberty to switch over, and any concerns about migration, backwards compatibility etc. are up to them. Several major tool authors were consulted for the design repeatedly across the discussion thread, over a period of months (and this is just the latest attempt at the design task; the total history is much longer).

uv has an issue up already to track implementation: https://github.com/astral-sh/uv/issues/12584

The PEP has buy in from all the major tools.

PEP 518 gave the original definition for pyproject.toml contents, defining its use for describing build-time requirements. (PEP 517 appeared more or less in tandem, describing the hook to call an entry point for the build backend; later, PEP 621 standardized some metadata for the build backend to use.) Many other options were considered, including for the name: https://peps.python.org/pep-0518/#other-file-names