`pipenv requirements` mode considers pipfile.lock but docs reference Pipfile

[mungojam]

Apologies if I've missed an existing feature request, I had a search through and couldn't find one.

Is your feature request related to a problem? Please describe.

The serverless-wsgi plugin generates a requirements.txt from pipfile, before installing those requirements. There are other tools that also rely on requirements.txt. But one limitation of requirements.txt vs. pipenv is that it doesn't provide any guarantees of sub-dependency versions.

If there were a pipenv requirements mode that would generate a requirements.txt file with all locked dependencies specified, then that would bridge the divide and allow us to ensure that the locked dependencies in pipfile.lock were used by these external tools.

Describe the solution you'd like

Much like pipenv sync only considers the pipenv.lock file, a new argument to pipenv requirements would make it generate a requirements.txt file from all the dependencies in pipfile.lock. I assume it would need to list the lowest level dependencies first in order to ensure that they didn't get installed twice which might happen if top level dependencies were listed first.

[matteius]

@mungojam My understanding is pipenv requirements was built to only consider the existing Pipfile.lock whereas the old install -r regenerated the lock file.

[mungojam]

The docs only mention pipfile in the example so perhaps that is what needs some tweaking

[matteius]

@mungojam That could be, I just checked the implementation and in fact, the original feature requests and author wanted the requirements command to be generated from the lock file, and it simplified the implementation of the install and lock commands (still very complicated).