Add a pip-style `--upgrade-strategy` setting to `pipenv lock`?

pip install these days offers an --upgrade-strategy option to let users choose between “only-if-needed” upgrades (which upgrades components only if needed to satisfy new dependencies) and “eager” upgrades, which upgrades everything which has a newer version available that still meets the dependency constraints.

In pip 10, the default strategy is changing from eager to only-if-needed: https://github.com/pypa/pip/pull/4500

pipenv lock currently follows the original pip install --upgrade policy of “upgrade everything”.

This is actually fine for my own current use cases - most of my dependencies are stable enough that the combination of loose dependencies in Pipfile and eager upgrades in pipenv lock works well. I also think this remains the right default behaviour for pipenv.

However, I’m wondering if permitting pipenv lock --upgrade-strategy=only-if-needed may make pipenv applicable to more use cases.

[brettdh]

I’d like to push back here. only-if-needed is a much more sensible default in my view, particularly coming from other package managers such as npm, yarn, and gem. If packages are automatically upgraded when doing so is not required, then the lockfile is not a lockfile; it’s just a suggestion.

The whole point of the lockfile is to pin dependencies to a known working version - to not have to assume that “most of my dependencies are stable enough”; to make all upgrades explicit (which, of course, is better than implicit).

I started this line of conversation in #966, but maybe this (or another issue) is a better place for it. Having --upgrade-strategy in pipenv would be a fine stopgap, but I maintain that only-if-needed is a more sensible default, as evidenced by pip 10 and the aforementioned package managers. The current situation doesn’t allow either, which makes pipenv a less reliable tool for locking down dependencies.

[mimischi]

I agree with what @Telofy said. Deterministic builds would be really helpful and I actually thought pipenv was trying to do that with Pipfile.lock.

Let’s say I write a Django app and use packageA==1.0.0, while there is a new version packageA==2.0.0 with breaking changes, that I do not want to include in my project. Upon upgrading to django==2.0.0, I add packageB via pipenv install packageB. Now pipenv will upgrade packageA to it’s newest version, while I may wanted to keep the old version to keep my project from breaking.

In that case: what are my options? Pin down dependencies in Pipfile instead of using * as the version argument?

So far I’ve been using requirements.txt and pinned down version by hand / using services like https://pyup.io.