[isjustintime]

This is great. pip-tools` is so valuable right now in helping mitigate these dependency tree issues. I'd love to see some form of support in core Python. I really hope this becomes pushed out, similar to how `pip` actually has a dependency resolver now. Relying on running `pip freeze` to create a quasi-lock is a horrible pattern for enterprise environments and for packages. I'm really looking forward to how this turns out, even though it's still in a proposal-type phase. `

[zahlman]

Pip has had a dependency resolver since 2020, it just had some issues initially (in large part because of the terrible state of metadata in the ecosystem). There are plenty of other problems with Pip, of course, and not having an obvious way to save and reproduce a package resolution is one of them.

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.