Why should version numbers not be pinned in a Pipfile?
Question:
I’m looking into using pipenv and in the docs here
https://pipenv.pypa.io/en/latest/basics/#importing-from-requirements-txt
it says (emphasis mine)
Note, that when importing a requirements file, they often have version
numbers pinned, which you likely won’t want
Why is this?
I understand that the Pipfile.lock file will store the specific versions and hashes of the dependencies I install but don’t I want to be able to see the specific versions of what is installed in Pipfile? (The same way I do when I use a requirements.txt?)
Answers:
don’t I want to be able to see the specific versions of what is installed in the Pipfile?
The lock file is for tracking what is actually installed, and is the key to generating deterministic builds. Pipfile.lock is intended to be committed to a project along with the Pipfile. There is also the view that an ideal workflow is use “pipenv lock to compile your dependencies on your development environment and deploy the compiled Pipfile.lock to all of your production environments for reproducible builds.”
Some versions you will want to specify in Pipfile. For example, all versions of Django below a certain major version is likely a good idea.
Also understand that as of now, pipenv is still under active development, so some of these ideas are still being worked out. It’s possible there could be some changes.
I’m not sure what the case was previously, however, the latest documentation says that you can specify the version number for a package when you install it, like this:
pipenv install requests==2.13.0
This will also update the package in your Pipfile to include the version number, which looks like this:
requests = "==2.13.0"
You can do this for each of the packages you want to specify version numbers for—including if you’ve previously installed them.
I think you may be able to manually edit your Pipfile to do this, although I’m not sure if that’d be correct.
The docs are quite opinionated on the likely reason you have pinned versions on your requirements file: it probably came from pip freeze > requirements.txt.
Of course you’ll want to specify some or all version ranges in your Pipfile, it’s just that many people have them pinned in the requirements.txt because they used to treat it like a kind of Pipfile.lock, specifying versions of packages that aren’t even direct dependencies. Naturally, if you didn’t follow this practice, you don’t have to worry about that warning.
This is very likely the result of Kenneth Reitz (Pipenv creator) himself doing that previously, as mentioned in his blog post A Better Pip Workflow. Clarification on this matter was already asked and answered by him in the official repository.
UPDATE JUNE, 2018
That message used to be printed as a warning by the pipenv command as well, but it has been replaced with
requirements.txt found, instead of Pipfile! Converting…
Warning: Your Pipfile now contains pinned versions, if your requirements.txt did.
We recommend updating your Pipfile to specify the "*" version, instead.
A little bit more friendly, but I think it’s still implicitly saying that pinning versions on Pipfile is not ideal, which is not true. It’s perfectly fine.
I’m looking into using pipenv and in the docs here
https://pipenv.pypa.io/en/latest/basics/#importing-from-requirements-txt
it says (emphasis mine)
Note, that when importing a requirements file, they often have version
numbers pinned, which you likely won’t want
Why is this?
I understand that the Pipfile.lock file will store the specific versions and hashes of the dependencies I install but don’t I want to be able to see the specific versions of what is installed in Pipfile? (The same way I do when I use a requirements.txt?)
don’t I want to be able to see the specific versions of what is installed in the Pipfile?
The lock file is for tracking what is actually installed, and is the key to generating deterministic builds. Pipfile.lock is intended to be committed to a project along with the Pipfile. There is also the view that an ideal workflow is use “pipenv lock to compile your dependencies on your development environment and deploy the compiled Pipfile.lock to all of your production environments for reproducible builds.”
Some versions you will want to specify in Pipfile. For example, all versions of Django below a certain major version is likely a good idea.
Also understand that as of now, pipenv is still under active development, so some of these ideas are still being worked out. It’s possible there could be some changes.
I’m not sure what the case was previously, however, the latest documentation says that you can specify the version number for a package when you install it, like this:
pipenv install requests==2.13.0
This will also update the package in your Pipfile to include the version number, which looks like this:
requests = "==2.13.0"
You can do this for each of the packages you want to specify version numbers for—including if you’ve previously installed them.
I think you may be able to manually edit your Pipfile to do this, although I’m not sure if that’d be correct.
The docs are quite opinionated on the likely reason you have pinned versions on your requirements file: it probably came from pip freeze > requirements.txt.
Of course you’ll want to specify some or all version ranges in your Pipfile, it’s just that many people have them pinned in the requirements.txt because they used to treat it like a kind of Pipfile.lock, specifying versions of packages that aren’t even direct dependencies. Naturally, if you didn’t follow this practice, you don’t have to worry about that warning.
This is very likely the result of Kenneth Reitz (Pipenv creator) himself doing that previously, as mentioned in his blog post A Better Pip Workflow. Clarification on this matter was already asked and answered by him in the official repository.
UPDATE JUNE, 2018
That message used to be printed as a warning by the pipenv command as well, but it has been replaced with
requirements.txt found, instead of Pipfile! Converting…
Warning: Your Pipfile now contains pinned versions, if your requirements.txt did.
We recommend updating your Pipfile to specify the "*" version, instead.
A little bit more friendly, but I think it’s still implicitly saying that pinning versions on Pipfile is not ideal, which is not true. It’s perfectly fine.