`pip install -U` upgrades already satisfied dependencies

[ejucovy]

If I pip install -U foo, I would expect that the latest version of foo will be installed, and foo'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:

$ pip install -U django-supervisor
Downloading/unpacking django-supervisor
  Downloading django-supervisor-0.2.0.tar.gz
  Running setup.py egg_info for package django-supervisor
Downloading/unpacking supervisor (from django-supervisor)
  Downloading supervisor-3.0a10.tar.gz (438Kb): 438Kb downloaded
  Running setup.py egg_info for package supervisor
    no previously-included directories found matching 'docs/*.pyc'
    no previously-included directories found matching 'docs/.build'
Downloading/unpacking meld3>=0.6.5 (from supervisor->django-supervisor)
  Downloading meld3-0.6.7.tar.gz
  Running setup.py egg_info for package meld3
Installing collected packages: django-supervisor, supervisor, meld3
  Found existing installation: django-supervisor 0.1.1
    Uninstalling django-supervisor:
      Successfully uninstalled django-supervisor
  Running setup.py install for django-supervisor
  Found existing installation: supervisor 3.0a10
    Uninstalling supervisor:
      Successfully uninstalled supervisor
  Running setup.py install for supervisor
    no previously-included directories found matching 'docs/*.pyc'
    no previously-included directories found matching 'docs/.build'
    Skipping installation of /usr/local/ejucovy/django/lib/python2.6/site-packages/supervisor/__init__.py (namespace package)
    Installing /usr/local/ejucovy/django/lib/python2.6/site-packages/supervisor-3.0a10-py2.6-nspkg.pth
    Installing echo_supervisord_conf script to /usr/local/ejucovy/django/bin
    Installing pidproxy script to /usr/local/ejucovy/django/bin
    Installing supervisorctl script to /usr/local/ejucovy/django/bin
    Installing supervisord script to /usr/local/ejucovy/django/bin
  Found existing installation: meld3 0.6.7
    Uninstalling meld3:
      Successfully uninstalled meld3
  Running setup.py install for meld3
Successfully installed django-supervisor supervisor meld3
Cleaning up...

My "existing installations" of supervisor-3.0a10 and meld3-0.6.7 are both "successfully uninstalled", and then identical versions are installed.

[hltbra]

In my judgement it is a known behavior, don't know if it is really a bug - I guess easy_install has the same behavior.

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

[hltbra]

Related to issue #49

[carljm]

It is a bug, and it is a duplicate of #49.

[ejucovy]

I don't think it's a duplicate of #49. I read #49 as saying that install -U foo shouldn't reinstall foo itself if it's already at the latest version -- which is different from whether or not it should reinstall foo's already-satisfied dependencies.

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:

• foo 0.1 depends on lxml>=2.3.0
• foo 0.2 is released, and depends on lxml>=2.3.0 (same dependency)
• lxml 2.4.0 is released

If I've already installed foo 0.1 and lxml 2.3.0, and I pip install -U foo, I wouldn't want it to install lxml 2.4.0. It should only install lxml 2.4.0 when foo starts to depend on lxml>=2.4.0.

[carljm]

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.

[ejucovy]

Would an extra command-line option be appropriate? pip install foo --upgrade vs pip install foo --upgrade-recursive? (Or --upgrade-nonrecursive if preserving the current behavior backwards-compatibly is important)

[nisavid]

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 upgrade P, not upgrade P --but-not-other-things.

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 emerge --update @world without --deep).

[cls]

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.

[ex-nerd]

This appears to happen with -I as well as -U.

[carljm]

Since -I stands for --ignore-installed, and is intended to make pip operate as if nothing were currently installed, reinstalling everything is the correct behavior for -I. Thus the behavior here is only a bug for -U, not for -I.

[jvanasco]

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.