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 will grow a new command line option,
--pipfile to install the versions as specified in a
Pipfile , similar to its existing
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?
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
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).
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.