New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to perform non-eager upgrades #3871

Closed
pradyunsg opened this Issue Jul 24, 2016 · 12 comments

Comments

Projects
None yet
4 participants
@pradyunsg
Member

pradyunsg commented Jul 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Jul 24, 2016

Member

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.
Member

pradyunsg commented Jul 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthew-brett

matthew-brett Sep 11, 2016

What is the status of this work now?

matthew-brett commented Sep 11, 2016

What is the status of this work now?

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Sep 15, 2016

Member

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.

Member

pradyunsg commented Sep 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Sep 17, 2016

Member

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.

Member

dstufft commented Sep 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthew-brett

matthew-brett Sep 17, 2016

The new flag sounds reasonable to me.

matthew-brett commented Sep 17, 2016

The new flag sounds reasonable to me.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Sep 17, 2016

Member

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

Member

pfmoore commented Sep 17, 2016

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

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Sep 17, 2016

Member

Sounds good to me too.

Member

pradyunsg commented Sep 17, 2016

Sounds good to me too.

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Apr 5, 2017

Member

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...

Member

pradyunsg commented Apr 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg May 16, 2017

Member

Bump.

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

Member

pradyunsg commented May 16, 2017

Bump.

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

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft May 19, 2017

Member

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

Member

dstufft commented May 19, 2017

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

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg May 19, 2017

Member

Cool. :) I'll make a PR?

Member

pradyunsg commented May 19, 2017

Cool. :) I'll make a PR?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft May 19, 2017

Member

Sure!

Member

dstufft commented May 19, 2017

Sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment