Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Pin `pipenv install X` to compatible version of X in Pipfile instead of *

See original GitHub issue

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

In my experience, pipenv seems to be a bit too eager to update to newer versions of dependencies (see e.g. #1219). Based on other tools like cargo and npm, I would expect pipenv install in a newly checked out project to get me a working environment for running the project. However, since pipenv install X pins to X = "*" in the Pipfile, it is possible that I’ll get newer versions of the deps incompatible with the given project.

Describe the solution you’d like

See also

Maybe Pipenv should do what npm does and make pipenv install pin to the major version instead of '*'.

I think it would be great if pipenv install X pinned to X = "~=<current_version>" instead of X = "*", ideally by default (but I admit my perspective may be limited by my particular use cases) or at least through an option that can be specified on the command line and/or in the Pipfile itself, something like --pin-to-current / pin_to_current = true.

Describe alternatives you’ve considered

What I’m doing currently is trying to remember to run pipenv install --ignore-pipfile instead of pipenv install when setting up a project for development on a new machine. However, this skips all updates, even compatible ones (bug / security fixes etc.), since the purpose of --ignore-pipfile is deterministic builds for production, not setting up a compatible environment for development.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:20
  • Comments:20 (11 by maintainers)

github_iconTop GitHub Comments

uranusjrcommented, Jun 22, 2018

The general proposition of using ~= (or even ^=, which does not exist in pip) is still valid, and I have seen this raised quite a few times now. * means every re-lock and update could potentially break user code because a new major version is released and it is not compatible with the application.

You could argue the user should be aware of this, and use e.g. django~=2.1.0 in the first place. But still, there is no good way to say “I want the latest ~= possible” instead of manually looking it up. It would be immensely helpful to either a) set this as default, and require django==* to explicitly get *, or b) have a command flag as mentioned above (an option in Pipfile less so IMO).

While the problem described is probably fixed, the user experience side of this proposition is still worth discussing.

dlukescommented, Jun 22, 2018

Sorry, I should have given a more concrete user story in the OP to make the issue clearer 😃 For instance:

  1. I start a website project, do pipenv install flask. This puts flask = "*" in my Pipfile and installs the latest version of flask, say 0.12.3.
  2. I deploy a working version of the project (using pipenv install --ignore-pipfile to get the exact same dependencies as those used in development).
  3. After some time, it turns out it’s necessary to add a new feature to the project. In the meantime, I’ve either switched computers or simply deleted my local dev copy of the project, or perhaps a new team member will be implementing the new feature – in all these cases, the dev environment has to be set up from scratch. These are the options:
    • pipenv install: this will install the latest flask 1.0.2, which may very well have some incompatibilities with 0.12.3, the version my project was originally developed with
    • pipenv install --ignore-pipfile (like when deploying): this will install the original version 0.12.3 of flask, but in the meantime, 0.12.4 has also been released, which should be compatible with the originally used version but probably contains bug and security fixes that I shouldn’t ignore…
    • … which means that what I should really do is manually look up the originally used version of flask in Pipfile.lock, change flask = "*" in the Pipfile to flask = "~=0.12.3", and onlye then do pipenv install, which will get me flask 0.12.4

I think the last behavior is the most useful one, yet it is the hardest one to achieve (the only one which involves manual operations). If the goal of the current default behavior of pipenv install (see first bullet above) is to nudge pipenv users towards ditching obsolete dependencies, I think that could be achieved in a less jarring way by just warning them that a newer version exists but won’t be installed because of compatibility requirements.

As @uranusjr says, it’s a user experience issue:

You could argue the user should be aware of this, and use e.g. django~=2.1.0 in the first place. But still, there is no good way to say “I want the latest ~= possible” instead of manually looking it up.

I couldn’t agree more.

Another possibility is that I’m using pipenv completely wrong, in which case please point out the problems with the workflow above and I’ll think about how the docs could be improved to better communicate pipenv’s intended usage patterns 😃

Read more comments on GitHub >

github_iconTop Results From Across the Web

Basic Usage of Pipenv - Read the Docs
--dev — Install both develop and default packages from Pipfile . · --system — Use the system pip command rather than the one...
Read more >
pipenv Documentation
pipenv install is fully compatible with pip install syntax, for which the full documentation can be found here. Note that the Pipfile uses...
Read more >
Set python version when creating virtualenv using pipenv
How do I set up pipenv to look for Python 3.6, when I first create the virtualenv? I can manually go in and...
Read more >
Advanced Usage of Pipenv — pipenv 11.7.2 documentation
Dependencies of wheels provided in a Pipfile will not be captured by ... resolved (1.10.1 installed)! Django before 1.8.x before 1.8.16, 1.9.x before...
Read more >
By default pipenv-setup check passes when the version specifies is "compatible" with Pipfile , i.e. is a subset of it. For example,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found