Implement installation from PEP 751 aka standardized lockfiles

[the-gabe]

What's the problem this feature will solve?

I am interested in PEP 751 so that developers can leverage the official python pip package manager to install and manage dependencies with strong security assurances.

I'm creating this issue to track the implementation of this matter as I am highly interested in this.

Describe the solution you'd like

pip implementing PEP 751.

Alternative Solutions

.

Additional context

https://peps.python.org/pep-0751/

Code of Conduct

• [x] I agree to follow the PSF Code of Conduct.

[pfmoore]

As pip is a volunteer-based project, contributions are welcome. This is definitely something we want to do, so it's just a matter of someone finding the time to implement it.

[sbidoul]

The lock file parser, as a first step towards this, is in progress in #13369

[stonebig]

Will pip implementation of the lockfile standard allow this ?

• step1: download a full hash256 list of wheels from pypi (and more) into a ./WheelHouse local directory
• step2: install the same wheels with the same pylock file from the local ./WheelHouse directory

That would require having the possibility to bypass the url defined in the lockfile, if there is one.

[ncoghlan]

Just adding a specific mention of pylock.toml to help this issue show up in searches for "pip pylock.toml"

[stonebig]

I did try copilote free on it, on the idea proposed per uv that it could be managed like a requirement: "-r pylock.toml" it downloads or install the file, but I'm not sur it makes the hash controls. ... to tease more motivated and AI equiped contributors: https://github.com/stonebig/pip/tree/pylock

[pfmoore]

I would like to be clear that we will not accept AI-generated PRs unless the submitter is fully confident in any generated code, and able to explain and discuss the PR in depth. To put this another way, you are responsible for any code you submit, and the pip maintainers do not have the time to review AI generated code.

Having said that, I took a quick look at the branch you linked to, and there's a lot of problems with it - unnecessary changes that are unrelated to the feature being implemented, a (very basic and IMO completely insufficient) reimplementation of #13369, and for no reason I can see, it replaces the existing get_requirements call with inline code that I frankly have no interest in validating to ensure it works the same as the current code.

If this is the sort of quality we can expect from AI-generated PRs, I'm a strong -1.

Debates over AI generated code aside, though, if anyone is interested in working on this, please be aware of #13369, which is a building block for any pylock installer, and please ensure that you have an agreed design on what "lockfile support" will entail (e.g. do we want to support lockfiles in pip download as well as pip install, how will we handle options like --platform, etc?) It's perfectly OK to start with limited goals and leave extensions for later, but it's not OK to simply ignore the bigger design questions. A good starting point would be to answer the questions in https://github.com/pypa/pip/issues/13334#issuecomment-2849141945