I understand the logic, but using the same exact --dev flag for opposite behaviors smells funny to me 🙊

Edit

Did i get this right?

• installing only dev dependencies is possible using (ok, edge case use)

pipenv lock -r -d > requirements-dev.txt && pip install requirements-dev.txt

Yet another very frustrating roadblock for us. We’re trying to work around #1356 and #3586, which are basically killing us. We decided to just convert the Pipfile.lock to a requirements.txt because we know we can rely on pip install to actually fail when it fails. But pipenv lock -r --dev was not working as expected/documented. So then I came across this issue.

We completely disagree with the assertion that the documentation is wrong. It makes no sense for --dev to work differently here than it does in install, et. al. If you see a use case for dev-only requirements files, then add --dev-only, or, at the very least, PLEASE give us a --default-and-dev option so we can generate one file with everything. What should be a simple pipenv install --dev --deploy for us has now become the following, and it’s horribly frustrating:

    pipenv lock --requirements > .tmp_requirements.txt
    pipenv lock --requirements --dev > .tmp_requirements_dev.txt
    pip install -r .tmp_requirements.txt
    pip install -r .tmp_requirements_dev.txt
    rm .tmp_requirements*.txt

In my case, I’m using the old-fashioned requirements.txt to build Docker images.

Therefore, it’s extremely needful to have pipenv lock -r generating only default deps and pipenv lock -r -d generating both (default & development) dependencies together so I can build separate images for development and production.

As workaround, I have to manually add -r ./requirements.txt to my requirements_dev.txt which minimizes extra work but still far from optimal.

Honestly, I don’t know if there is a better way to work with Docker images while using/adopting pipenv since this is the first time I use pipenv. if you know a better way, please point me to the right direction.

Let me try to clarify it. We re-organized the commands and options to reduce repetitions. And the --dev option is taken from a common option, which is documented as “install both develop and default packages”, whereas, as you found, behaves differently between commands.

In the context of lock -r, it is likely that people use it to generate the old-fashioned requirements.txt and dev-requirements.txt, so it is more expected the two sections are generated separately. Now what we should do is to replace the common option to a specific one with the correct document string to reflect what it does. Contributions are welcomed.

It is just my opinion and it might be wrong. Kenneth should have some words for it.

+1 from me for @frostming’s proposal (cc @techalchemy).

We just ran into this in a docker build after switching to pip-sync to work around #3057 (since pip-sync removes non-matching packages, unlike pipenv sync, it’s more sensitive to transitive dependencies being missing from the locked output).

In our case, we can work around it by removing the production/dev distinction (as our production deployments don’t go through pipenv, they use a separate pip-compile invocation), but the general case needs --dev to work the same way it does in other commands.

@layoaster I struggled with this while trying to build docker images too - also the first time I’m using pipenv.

I found a way to use the Pipfile.lock and this command: pipenv install --ignore-pipfile --system --deploy --dev when building the image.

Currently I’m installing all the packages in the image, as I use the same image to test and run in production.

@gtalarico I just changed my mind and modified the previous comment a lot, sorry for the trouble.