Surprising `pipenv install` behaviour regarding the lockfile

I’m afraid I the pipenv.help command couldn’t find pipenv, so I couldn’t run it. I’m running v10.1.2, and I was very surprised to see that pipenv install does not use the lockfile by default! This led to a crash where my package could not be installed, as pipenv install on the end user’s machine tried to upgrade the lockfile and broke. pipenv install --ignore-pipfile worked fine, but it was extremely surprising to me that this wasn’t the default.

Basically, I consider pipenv install without any arguments to be a distribution-time command, ie it will be run when I want to distribute my package and install all the requirements. I would expect this to use the lockfile, if available.

I realize that pipenv install <somepackage> is a development-time command, breaking symmetry, but the way I imagined things working regarding the lockfile was that a command like pipenv install <package> would change both Pipfile and Pipfile.lock, a command like pipenv lock or pipenv upgrade would upgrade packages in the lockfile, and a command like pipenv install would use that lockfile to install packages.

I think many people will be bitten by the surprising default behavior of pipenv install to not only not use the lockfile, but to upgrade it as well, and the main problem is that nobody will realize what’s happening until stuff blows up.

If you won’t consider changing pipenv install to use the lockfile, maybe a separate command could be added.

I just now realized that pipenv sync is close to what I want, but it seems to be an alias for pipenv install --keep-outdated. Does that mean that new versions of the packages will be installed, but the lockfile won’t be changed? That’s what “Keep out–dated dependencies from being updated in Pipfile.lock.” seems to imply, ie that it will install the new dependencies but won’t touch the lockfile. Also, pipenv sync doesn’t seem to use the Pipenv file if a lockfile does not exist.

To sum up, I am concerned that the commands are, at least, not documented well enough/a bit unclear. What is the recommended way, currently, of using the lockfile if it exists, or the Pipfile otherwise?

[skorokithakis]

No, I don’t want it to abort. Consider this scenario: I developed, tested, froze all my dependencies, etc. Now, a month later, when all the red tape has been cleared, I want to deploy what I tested, with all the dependencies I used when testing, etc to production. I don’t want pipenv to upgrade anything, I don’t want it to fail if there are new packages: I want it to install the exact versions, to the byte, of what’s in the lockfile.

[kennethreitz]

A bare pipenv install will always use the pipfile.lock, if the hashes match.