Pass `--upgrade-strategy=eager` on pip 10+

[ncoghlan]

Pip 10 is changing its default upgrade strategy to "only-if-needed", which isn't the desired behaviour for pipenv's purposes.

In order to retain its current "upgrade everything to the latest version available" behaviour when regenerating the lockfile, pipenv will need to pass --upgrade-strategy=eager when calling pip.

(This issue replaces #418)

[kennethreitz]

Thank you.

[kennethreitz]

This shouldn't effect our codebase. But, we'll see :)

[brettdh]

This does seem to affect pipenv lock, as it doesn't use pip's upgrade strategy settings, and so can result in inconsistent behavior: https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339312709

[erinxocon]

@brettdh Are you using python3.7?

[brettdh]

@erinxocon 3.6.2

[erinxocon]

What is the timeline of pip10's release?

[brettdh]

No idea. Where would that information be? The 10.0 GitHub milestone has no due date.

…

On Wed, Oct 25, 2017 at 5:40 PM erinxocon ***@***.***> wrote: What is the timeline of pip10's release? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/pipenv/issues/438#issuecomment-339480257>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFlnsJglff0ZCsXLFvAbmjJbsTB5FhVks5sv6rrgaJpZM4OassP> .

[nateprewitt]

This suggests it's soon. We've been putting off making a decision on this (unless the decision is to do nothing) for a while. Either we wait for problems to crop up after release or we preemptively force the eager check for backwards compat.

[erinxocon]

@nateprewitt Forgive my ignorance on the subject, but since we use a vendored/patched version of pip would we have to update our pip or would our pip be unaffected.

[nateprewitt]

@erinxocon, I believe it still would because the pip installed in the users environment is coming from the attached Python the virtualenv is built on, not our vendored one which only affects the pipenv code itself.

[brettdh]

@nateprewitt see the issue I linked above; those aren’t the only options, and there are already problems. It would be ideal if pipenv allowed setting the upgrade strategy, whether as a cli flag or env var. For those that depend on anything but pip’s default, pipenv has undesirable behavior.

…

On Thu, Oct 26, 2017 at 12:10 AM Nate Prewitt ***@***.***> wrote: @erinxocon <https://github.com/erinxocon>, I believe it still would because the pip installed in the users environment is coming from the attached Python the virtualenv is built on, not our vendored one which only affects the pipenv code itself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/pipenv/issues/438#issuecomment-339545813>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFlnksnYc9uS7DcNL6DsI3PAk4WaWNOks5swAZEgaJpZM4OassP> .

[techalchemy]

Right I think we understand that you want to be able to do more. This discussion is about what the default behavior should be when pip changes its default behavior. I’m guessing we should keep our current behavior but provide an easy interface to change it.

…

On Oct 26, 2017, at 6:28 AM, Brett Higgins ***@***.***> wrote: @nateprewitt see the issue I linked above; those aren’t the only options, and there are already problems. It would be ideal if pipenv allowed setting the upgrade strategy, whether as a cli flag or env var. For those that depend on anything but pip’s default, pipenv has undesirable behavior. On Thu, Oct 26, 2017 at 12:10 AM Nate Prewitt ***@***.***> wrote: > @erinxocon <https://github.com/erinxocon>, I believe it still would > because the pip installed in the users environment is coming from the > attached Python the virtualenv is built on, not our vendored one which only > affects the pipenv code itself. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/kennethreitz/pipenv/issues/438#issuecomment-339545813>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAFlnksnYc9uS7DcNL6DsI3PAk4WaWNOks5swAZEgaJpZM4OassP> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.