Provide a way to perform non-eager upgrades

[pradyunsg]

Ref #59, #3786

pip should provide a way to do non-eager upgrades, i.e. upgrade a dependency only if it no longer satisfies the newer parent version requirements.

To be decided:

• Should this behaviour be default?
• If so, should the current behaviour (eager upgrades) be kept and exposed?

[pradyunsg]

My answers to the questions in OP are:

• Yes.
• I don't need it but someone might so, let's keep it for a little while... deprecated state?

Quoting myself from #3786:

a minimum disruption change would be:

• pip install --upgrade provides non-eager upgrades by default.
• Add a --upgrade-strategy=[eager/non-eager] (with any spelling) to choose your upgrade strategy, iff you really want to provide eager upgrades.

[matthew-brett]

What is the status of this work now?

[pradyunsg]

It got stalled because I ran out of free time. And another time, I messed up the permissions on my system and ate up time trying to fix it instead of working on this.

I have an unpushed, partially tested patch that I was planning to visit this weekend to polish and publish, hopefully as another PR.

[dstufft]

Circling back to this now. Here's what I think we should do:

1. Add --upgrade-strategy=[eager/non-eager] in pip vX which defaults to eager, and allow people to opt-in to the non-eager strategy. This will allow us to get some real world testing from people without forcing a change on everyone at once.
2. Once we've addressed any feedback from 1., switch the default of --upgrade-strategy to non-eager in pip vX+1. This will get us a lot of real world use by forcing a change on everyone, but gives an escape hatch for people who, for whatever reason are broken by the change.
3. Once we've addressed any feedback from 2., look at deprecating --upgrade-strategy in pip vx+2 (to be removed following our normal deprecation policy).

This will have a longer lead time before non-eager is the default, but it allows us to phase it in slower to make sure there's not some use case that's going to go kaboom from it. Ideally I think we'd want to eventually get rid of the --upgrade-strategy flag. That kind of flag feels like it's just asking for trouble with things breaking because it essentially requires us to duplicate our upgrade testing to actually fully test things. I do think it's a good flag to add for now though, to allow the phase in and dealing with any breakages.

[matthew-brett]

The new flag sounds reasonable to me.

[pfmoore]

Agreed, that sounds like a sensible way to handle this.

[pradyunsg]

Sounds good to me too.

[pradyunsg]

I guess pip 10.0 is the vX+1 @dstufft talked of. I would want to stall the switch one more major version cycle.

I say this because I'm (hopefully) gonna be able to tackle #988 in the near future, which would change the need for this switch...

[pradyunsg]

Bump.

Should the switch of the default happen in 10.0 or wait till 11.0?

[dstufft]

I think given our original timeline we'd make the change in v10.

[pradyunsg]

Cool. :) I'll make a PR?

[dstufft]

Sure!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.