What is the status on a pip lock file?

Greetings,

First, I’m inquiring about the status of Pipfile.lock file. My understanding is that it has been in a discussion phase and remains there. pipenv is the primary implementation as mentioned in the project README. However there is a section regarding eventual implementation into pip:

pip will grow a new command line option, -p / --pipfile to install the versions as specified in a Pipfile , similar to its existing -r / --requirement

Is integration with pip still a feature that is being explored?

Second, I realize there is focus on pip’s new package resolver. Is a lock file (or a similarly more robust mechanism to reproduce pip dependencies) part of that vision?

Many thanks.

Yes, see Add `pip install --dry-run` or similar, to get resolution result · Issue #53 · pypa/pip · GitHub

If implemented as a separate command (i.e. pip resolve instead of pip install --dry-run), this can be done even before --use-deprecated=legacy-resolver is dropped because the two wouldn’t overlap. But someone needs to actually put in the effort to make the command happen, and everyone seems to be focusing on other things right now. Either we wait for someone to put up volunteer work, or have to put up a plan to recruit someone to do it.

This is less obvious. Commenting as a pipenv maintainer, the current lock file format is likely too limiting to be useful for pip. It at least needs to grow more flexible grouping strategy. And as a pip maintainer, the benefit to pip resolve using a new lock file format is also not significant enough over requirements.txt.

Speaking for myself only, I would like to revive my Structured, Exchangeable lock file format design for this. It is now clear the new format will not happen as a standard because it’s not viable to design something that fits all tools’ needs, but the format will be an improvement to both requirement.txt and Pipfile.lock, and interoperability would be less of a problem with PEP 650. But again, the improvements may not be significant enough to convince pip maintainers as a team to adopt the new format, and status quo may win because it is already implemented and wildly used (even though poorly designed, ill specified, and has weird implementation edge cases).

3 Likes

I appreciate the response. I’m glad to see activity on the pip resolve idea.

My hope is that a robust lock file comes about soon. I have not had luck with reproducing conda environments that are mixed with pip packages. There are a few solutions that aim at conda packages, but avoid pip packages (likely because of the complexity):

  • conda (spec-file): conda-only
  • conda-lock: skip pip packages altogether
  • conda-pack: ignore missing pip packages

Your proposal seems to be a promising step in a helpful direction.