-
Notifications
You must be signed in to change notification settings - Fork 3k
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
pip install -U
upgrades already satisfied dependencies
#304
Comments
In my judgement it is a known behavior, don't know if it is really a bug - I guess I would like to see other's opinions. PS.: There was a question in StackOverflow related to this: http://stackoverflow.com/questions/5937756/why-is-pip-looking-for-download-cache-if-the-same-exact-package-is-already-instal |
Related to issue #49 |
It is a bug, and it is a duplicate of #49. |
I don't think it's a duplicate of #49. I read #49 as saying that This distinction matters for hard-to-build libraries which have frequent releases but fairly stable APIs -- for the most part, one installation is good enough -- I'd only want to reinstall it if my dependencies start to use newer features from those nested dependencies (i.e. if the requirement is no longer satisfied) -- for example:
If I've already installed |
Ah, yes, that is a bit different. Even if #49 is fixed, there would be some additional code needed to achieve the behavior you're wanting when the dependency is not at its latest version, but still satisfies the dependency requirements. I think if we made this change, some people would find it surprising. I can see why it's desirable in certain cases -- but I can also see cases where the current behavior (minus #49) is preferable. So I'm on the fence on this one. |
Would an extra command-line option be appropriate? |
making upgrades non-recursive by default would provide consistency with other package managers, such as APT and Portage. and i think there is a good reason for such behavior, which is that it avoids unintended side effects--if i want to upgrade a package P, then i would like to enter a command along the lines of on the other hand, i think that an "upgrade all" command (see #59) should be recursive by default, since "all" should really mean "all" by default. in this case, non-recursive behavior would mean "upgrade all packages installed directly, but not any dependencies that weren't installed directly" (like Portage's |
A related issue is that if the package being upgraded has a dependency on another package which is already installed but unavailable from a repository, Pip will fail and is unable to upgrade the requested package, despite its dependencies being fulfilled. |
This appears to happen with -I as well as -U. |
Since |
easy_install does not have the same behavior. easy_install will not re-install dependencies if they are already met. this isn't a feature or behavior, this is a bug. this is also really annoying -- testing PIP distribution for a framework's package , or updating a single framework add-on, means needing to re-install the entire framework and all of it's dependencies. these unnecessary downloads and installs are a waste of time and resources. |
for those who just want a way to do this now, short of a behavior/code change to "-U" I think this achieves the desired result, right? upgrade top-level requirements only:
|
For the simplest case that suffices, but I don't think that works for a requirements.txt file, or if there are dependencies which have updates to their install_requires. We have a complicated script that does a diff of our requirements.txt and more-or-less does what you describe, but it doesn't handle upgrade depth > 1. What complicates matters to an extent is that many django packages comment out or remove their install_requires lines because of this bug; otherwise they end up with some alpha version of django installed (that has been our experience, and I've seen it in the github issues of many prominent django packages. |
Hey @fdintino , I rigged up a basic test with requirements, -U, and --no-deps and it seemed to work, i.e. the items in the requirements file were upgraded, but no dependencies. that's consistent with my understanding of what the code is doing. it's tedious in there though, so there could be a failing with this idea. for the case where a top-level requirement has a new "install_requires" dependency, that's why I mentioned the 2nd pass command to install those. for the case where there are "are dependencies which have updates to their install_requires", I'm not sure I follow you there. you would only discover and want to act on that, if you were wanting to do a full recursive upgrade, right? |
Only if you no longer met the requirements. So, for example, if I updated django-sentry, and django-sentry required |
thanks @fdintino . I follow now. you don't want to cut off all recursive behavior (that will do necessary upgrades to fulfill requirements), just want to stop recursive "forced" upgrades. btw, your comment is cropped due to formatting. might want to fix that for others. |
I posted a gist that breakdowns achieving the desired behavior using the 2 commands in sequence mentioned above. https://gist.github.com/3088149 comment appreciated on the gist if this is not the scenario. |
I notice this has been open a long time. I found that my version of pip now has the option to do
This seems to be the desired behaviour, although rather verbose. Personally I think it'd have been great if this were the default, but maybe it's too late to change now. If it's too late to change the default, then I think this can be closed? |
In #3871 (comment) I mentioned what I believe to be the way we're going to move forward on this, reproducing here:
|
Okay sounds good, I'll wait for step 2 to complete. Seems that other issue is a duplicate, but already closed. |
@xavfernandez @dstufft Can this be closed or will we wait till the default switches? |
We'll probably wait till the default switches. |
Closing, since #4500 was merged |
If I
pip install -U foo
, I would expect that the latest version offoo
will be installed, andfoo
's dependencies will only be reinstalled if they're not already satisfied. But in fact the dependencies all get reinstalled even if I already have identical versions installed:My "existing installations" of
supervisor-3.0a10
andmeld3-0.6.7
are both "successfully uninstalled", and then identical versions are installed.The text was updated successfully, but these errors were encountered: