Add --pipfile Pipfile.lock as an alternative of -r requirements.txt

[olibre]

What's the problem this feature will solve?

I use container to deploy Python application to production. The container building script performs the following command lines:

python3 -m pip install pipenv
python3 -m pipenv sync  # Install modules from Pipenv.lock 
python3 -m pipenv run python3 -m pip freeze > requirements.txt
python3 -m pip install -r requirements.txt
python3 -m pip uninstall pipenv
rm requirements.txt

Describe the solution you'd like

Replace the above command lines by just one pretty pip option:

python3 -m pip install --pipfile Pipfile.lock

Additional context

The project https://github.com/pypa/pipfile/blob/master/README.rst states:

Pipfile and its sister Pipfile.lock are a replacement for the existing standard pip's requirements.txt file.

Let's start the movement by adding an experimental option in next pip release 😄

EDIT: My colleague has just pointed me that this has already been (eventually) planed. The same document, at chapter Pip Integration (eventual) says:

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 argument for installing requirements.txt files.

[pfmoore]

I'm not sure there's consensus that pipenv.lock is a replacement for requirements.txt (regardless of what is stated in that project's repository) and I'm cautious about adding an option to pip that is specific to another project (will we then get requests to add an option for Poetry's lock file format?)

At a minimum, I'd like to see some discussion within the community that resulted in agreement that pipenv.lock was a standard format, before adding this (and in particular, I'd like the poetry devs to have bought into that agreement).

[pradyunsg]

There's discussion about a standard lock file format: https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876

[pradyunsg]

Poetry's author hasn't really interacted much AFAICT -- @sdispater are you interested in helping figure out how to improve existing tooling?

[ncoghlan]

Also see pypa/pipfile#108 for discussion of some of the potential design details to be considered.

In the meantime, note that 'pipenv lock' includes native support for generating a requirements.txt file, so it isn't necessary to use pip freeze for that: https://docs.pipenv.org/en/latest/advanced/#generating-a-requirements-txt

[micheartin]

Homepage of Pipenv project seems to have changed, the link in the above message of @ncoghlan is broken, and should be:
https://pipenv.pypa.io/en/latest/advanced/#generating-a-requirements-txt

$ pipenv lock -r > requirements.txt
$ pipenv lock -r --dev-only > dev-requirements.txt

[tgross35]

Does anybody know where the relevant PR / active discussion / open issues are for implementing Pipfile support in pip? There doesn't seem to be much discussion on it, even though the specification seems to have stabilized (only changes to readme and a trivial __repr__ change since July 2020), unless I just don't know where to look.

With python 3.11 adding toml support, it seems like pip should aim to support Pipfile at least by then.

[uranusjr]

First, note that we are not planning to support Pipfile, but the lock file instead.

The current Pipfile.lock format is too implementation-oriented and cannot be used as-is, and an effort to standardise the lock format must be completed before the installation part can be implementation. You can find very extensive discussions on the topic by searching for lock file on https://discuss.python.org.

[uranusjr]

I’m going to close this for now. Threads on discuss.python.org provide much more context (probably way more than anyone would want, unfortunately), and having this open is misleading since we are likely never going to support the specific command proposed in the title.

[tgross35]

Thanks for the update. Guess I found the latest discussion - too bad it seems like the relevant PEP was rejected https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736/143

Any clue if there's a specific reason that pip wouldn't use the combined Pipfile + Pipfile.lock format (assuming the lock spec were to get tweaked to meet goals)? Having the human read/writable Pipfile plus the ugly hash-filled computer-generated Pipfile.lock has worked pretty well in my opinion (especially since a json lock is easier when a toml writer was pretty heftily rejected for python core). Kind of surprised pypa has had pip pipenv and pipfile under their umbrella for a while without pip supporting the spec.

Maybe time to update the pipfile readme if pip support is a permanent no-go, looks like it hasn't been touched in a while.

[uranusjr]

The main reason is Pipfile.lock is not a spec to begin with, but an implementation detail. A spec must be written; it may or may not be identical to the current Pipfile.lock format, but by definition would not be Pipfile.lock.