Skip to content
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

Add an upgrade-strategy option #3972

Merged
merged 7 commits into from
Sep 18, 2016
Merged

Conversation

pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Sep 16, 2016

Resolves #3871


Associate an upgrade-strategy with pip install --upgrade. The upgrade-
strategy determines how upgrading of the dependencies.

Provides 2 upgrade-strategies "eager" and "non-eager". "eager" upgrades
dependencies regardless of whether they currently satisfy the new parent
version-specification. "non-eager" upgrades dependencies if and only if
they do not satisfy the new parent version-specification.

PS: I've allowed write access to maintainers (there was this checkbox) on this branch but I don't think that would be necessary.


Pinging (sorry if this is noise): @njsmith @xavfernandez @pfmoore @dstufft @rbtcollins @rgommers @dholth

As before, I would like it if we discussed all the implementation related stuff on this PR and use #3871 for all the other related discussions.

@@ -224,6 +236,14 @@ def run(self, options, args):
if options.build_dir:
options.build_dir = os.path.abspath(options.build_dir)

allowed_strategies = ["eager", "non-eager"]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'll ever add any new ones but this list should probably be kept close to the code actually performing the upgrade-or-not decision and be visible from here.

Please suggest what would be the correct/appropriate place to put this list of allowed upgrade strategies?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could instead just set add choices=["eager", "non-eager"] to the add_option call above. It should handle the error handling for you.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! I was wondering if I'm missing something obvious there...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'll ever add any new ones

--no-deps can also be considered an upgrade strategy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--no-deps can also be considered an upgrade strategy.

For the sake of simplicity, not in this PR. ;P Maybe add a new issue for this?

@pradyunsg
Copy link
Member Author

Travis failed on nightly for reasons I don't understand and pep8 because the test names are too long.

Copy link
Member

@dstufft dstufft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it's pretty close to being able to land.

@@ -224,6 +236,14 @@ def run(self, options, args):
if options.build_dir:
options.build_dir = os.path.abspath(options.build_dir)

allowed_strategies = ["eager", "non-eager"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could instead just set add choices=["eager", "non-eager"] to the add_option call above. It should handle the error handling for you.

cmd_opts.add_option(
'--upgrade-strategy',
dest='upgrade_strategy',
default='non-eager',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned in #3871 (comment) I think we'll want this to default to eager for this time and we'll make sure to file an issue to swap the default for the next X+1 release.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll push a commit for the same.

@dstufft
Copy link
Member

dstufft commented Sep 17, 2016

You can ignore the Python 3.6/nightly errors. That's not a problem with this branch. I'm talking to the Travis folks about getting an upgraded version of that available. Worst case I'll disable the matrix line.

@pradyunsg
Copy link
Member Author

@dstufft Thanks for the review.

I've made the changes that you suggested.

PS: Considering the size of the patch, I really think this should be squashed and merged...

@pradyunsg
Copy link
Member Author

Oh, and if this merges today, I have some time everyday for a week free to tackle any random issue. Any that comes to your head?

@dstufft
Copy link
Member

dstufft commented Sep 18, 2016

I generally squash merge changes anyways yea.

@dstufft
Copy link
Member

dstufft commented Sep 18, 2016

I need to get the 3.6 stuff fixed, going to poke at that now. If you have a chance to write a change log entry for this that'd be great. Otherwise I'll do it before I merge.

@pradyunsg
Copy link
Member Author

I think that the build is fixed. Should I rebase?

@dstufft
Copy link
Member

dstufft commented Sep 18, 2016

Go for it!

Associate an upgrade-strategy with `pip install --upgrade`. The upgrade-
strategy determines how upgrading of the dependencies.

Provides 2 upgrade-strategies "eager" and "non-eager". "eager" upgrades
dependencies regardless of whether they currently satisfy the new parent
version-specification. "non-eager" upgrades dependencies if and only if
they do not satisfy the new parent version-specification.
@pradyunsg
Copy link
Member Author

pradyunsg commented Sep 18, 2016

Done! Build is passing.

'--upgrade-strategy',
dest='upgrade_strategy',
default='eager',
choices=['non-eager', 'eager'],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to consider whether "non-eager" is clear to a user. The original proposal of "only-if-needed" is not much longer. That's what the pip docs call it now: https://pip.pypa.io/en/latest/user_guide/#only-if-needed-recursive-upgrade

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I'll make the change.

if best_installed:
skip_reason = 'already up-to-date'
elif self.upgrade_strategy == "non-eager":
skip_reason = 'not upgraded as not directly required'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gets appended to "Requirement already" instead of to "Requirement". Now it looks a bit weird: Requirement already not upgraded as not directly required

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and same two lines above, gives Requirement already already up-to-date

Copy link
Member Author

@pradyunsg pradyunsg Sep 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed that line. 😅 I thought I had changed it...

elif self.upgrade_strategy == "non-eager":
skip_reason = 'not upgraded as not directly required'
else:
skip_reason = 'already satisfied'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can't happen - if the above two clauses are false, then the latest version is not installed and strategy is eager. Hence can't skip but need to upgrade.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I think about it, yes. This is a need-to-upgrade. I don't know what reasoning I was applying earlier for this...

Copy link
Member Author

@pradyunsg pradyunsg Sep 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... I did that because of the assert on line 484. And because I could never hit that branch in any of my testing earlier, for the previous PR.

@rgommers
Copy link

rgommers commented Sep 18, 2016

Played around with this a little bit - behaves as expected. LGTM

@pradyunsg
Copy link
Member Author

Thanks for the review @rgommers!

@pradyunsg
Copy link
Member Author

The build broke for reasons not related to these changes (some 404 on hitting the web for generating docs).

@pfmoore
Copy link
Member

pfmoore commented Sep 18, 2016

I restarted the doc build

Copy link
Member

@pfmoore pfmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one minor nit noted, which is fine left as is.

# For link based requirements we have to pull the
# tree down and inspect to assess the version #, so
# its handled way down.
if not (self.force_reinstall or req_to_install.link):
try:
finder.find_requirement(req_to_install, self.upgrade)
finder.find_requirement(
req_to_install, upgrade_allowed)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't upgrade_allowed always be true here (line 414)? I guess the same was true of self.upgrade before, though...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered the same initially. Then I decided to keep it as it was with upgrade.

@pfmoore
Copy link
Member

pfmoore commented Sep 18, 2016

Weird, I reran the doc build twice, but it failed both times. I can fetch the offending file manually, though. Travis weirdness?

@pradyunsg
Copy link
Member Author

Thanks for the review @pfmoore!

Travis weirdness?

I think so...

@dstufft dstufft merged commit 807f879 into pypa:master Sep 18, 2016
@matthew-brett
Copy link

Nice ! Many thanks for this.

@pradyunsg
Copy link
Member Author

Would it be useful to update a section of the documentation as updated here: https://github.com/pypa/pip/pull/3806/files#diff-0fcaa96196be65c5d918fd5099ea19a8 to mention this new option?

@rgommers
Copy link

rgommers commented Dec 7, 2016

that makes sense to me. Later on (1-2 years?) the comments on history can be removed again, but for now they will be helpful

pradyunsg added a commit to pradyunsg/pip that referenced this pull request Jan 14, 2017
@pradyunsg
Copy link
Member Author

Made the PR: #4232

xavfernandez pushed a commit that referenced this pull request Jan 27, 2017
@pradyunsg pradyunsg deleted the non-eager-upgrades branch February 7, 2017 04:41
guewen added a commit to guewen/docker-odoo-project that referenced this pull request Jan 4, 2018
To prevent unnecessary upgrades of libraries. See pypa/pip#3972
guewen added a commit to TDu/docker-odoo-project that referenced this pull request Jan 11, 2018
To prevent unnecessary upgrades of libraries. See
pypa/pip#3972
@pradyunsg pradyunsg added the C: upgrade The logic of upgrading packages label May 11, 2018
@lock
Copy link

lock bot commented Jun 2, 2019

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.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: upgrade The logic of upgrading packages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide a way to perform non-eager upgrades
5 participants