Add a "Upgrade all local installed packages"

[jedie]

see also: #59

[jezdez]

This doesn't look to bad, although I have to admit I'm not certain how to handle editable requirements gracefully. Should they really be considered when upgrading? What if an editable requirement is fixed to a specific commit?

Other than that this looks not too bad, I wouldn't mind if the manual parsing of the vcs URL could be handle a bit nicer, there might be code that does that already -- probably in the freeze command.

[tkruse]

+1 on this feature, what is holding things up?
Also discussed here:
http://stackoverflow.com/questions/2720014/upgrading-all-packages-with-pip

[qwcode]

Usually you'll manage what versions you want for your project (and the associated virtualenv)
in a requirements.txt file or setup.py's install_requires
(or maybe both http://stackoverflow.com/questions/6947988/when-to-use-pip-requirements-file-versus-install-requires-in-setup-py/7085000#7085000)

for either of those case, we have upgrade solutions.

if managed via requirements.txt:
pip install -U -r requirements.txt (this will upgrade any specs that are not pegged to a specific version)

if managed via setup.py install_requires (in a local project in develop/editable mode)
pip install -U -e path/to/project (this will upgrade any specs that are not pegged to a specific version)

the only reason I see to move forward with this feature, is if we feel like we need to support upgrading an "undefined" virtualenv (or upgrading the global system packages, which sounds scary)

[tkruse]

For the professional developer a global system package update may sound scary. For a casual python user, pip is just yet another package manager like synaptic.

Meaning over the last year, a user installed several python tools via pip that he uses, and now he just thinks its time to get the latest and greatest, but he does not know nor care what the exact list of tools is he installed and wants to upgrade.

As an example, take this set:
PyYaml
argparse
bpython
ipython
mock
pip
Sphinx

I understand that a feature that completely changes an env can be harmful, I just try to explain the use case and the intended audience I see (though others might have different valid reasons to want such a feature).

[qwcode]

I looked at the associated issue.
It does look there was interest from multiple maintainers to do this a year ago.

They mentioned "pip upgrade" would be an alias to "pip install -U" for upgrading specific packages,
"pip upgrade -all" would be for a full upgrade across all packages.

as best I can tell this pull doesn't do that.

it seems it has "pip upgrade" being for upgrading what you specify plus all locally installed pkgs.

also, it doesn't limit the options shown. It inherits everything from "install", including "--upgrade"

I think more thought would need to be put into what options make sense for this.

[corydolphin]

@qwcode would you accept a "pip updates" which would list all packages with newer versions found? I feel that this would both allow a casual pythonist to see which packages are outdated, similar to synaptic, and for professional developers to ensure that they have access to the newest packages, allowing them to test as necessary.

It would be great to stop relatively complicated workarounds such as http://stackoverflow.com/questions/2720014/upgrading-all-packages-with-pip

A second command could be "pip updates --install" which would upgrade all packages.

Let me know your thoughts, I would love to make it easier for people to maintain current versions of packages.

[qwcode]

@wcdolphin , there's a "pip list" command soon to be merged that has --outdated and --uptodate options.
it's pull #675 plus some fixes and docs. I'm working on that now actually.

I'm open to an implementation of pip upgrade like mentioned above. sooner or later, I will do it myself, if nothing comes in. Be prepared to commit for the long haul if you want to see it merged. read all the old history on the related issues (#59, #571). think through all the angles. write tests.

[employ]

+1

[clarkevans]

Upgrading only local packages is important, --system-site-packages shouldn’t be part of the upgrade. Typically system site packages include dependencies upon "C" libraries that can't be upgraded easily.

[msabramo]

Hmmm, just from reading various comments here, I feel like upgrading all packages is the trickier part that needs a little thought, as how do you handle editables, system site packages, user packages, etc.
Probably solvable with some thought, but I wonder if it makes sense to break the problem down into multiple steps, where the first step is simply to support pip upgrade <package>. This is relatively easy and then someone can add pip upgrade --all or whatever later, which would be a bit tricker, but somewhat easier after having the plumbing from the first step.

Does a PR for pip upgrade <package> sound like something that could be merged?

[corydolphin]

How does that differ from pip install -U ?

I'm really hoping we can get some equivalent of gem/npm/bower install
--save. That to me is the largest pain point with pip today.

That and at a systems level, the fact that dependencies are duplicated for
libraries between requirements.txt and the setup.py. Would love to
coalesce.
On Thu, Mar 5, 2015 at 2:42 PM Marc Abramowitz notifications@github.com
wrote:

Hmmm, just from reading various comments here, I feel like upgrading all
packages is the trickier part that needs a little thought, as how do you
handle editables, system site packages, user packages, etc.
Probably solvable with some thought, but I wonder if it makes sense to
break the problem down into multiple steps, where the first step is simply
to support pip upgrade . This is relatively easy and then
someone can add pip upgrade --all or whatever later, which would be a bit
tricker, but somewhat easier after having the plumbing from the first step.

Does a PR for pip upgrade sound like something that could be
merged?

—
Reply to this email directly or view it on GitHub
#313 (comment).

[msabramo]

How does that differ from pip install -U ?

Because it's more intuitive and matches other tools, although now that I look at gem and npm, I guess that update is a better name than upgrade if we don't want to reinvent the wheel.

vagrant@vagrant-ubuntu-trusty-64:~$ gem update --help | grep 'Usage:'
Usage: gem update GEMNAME [GEMNAME ...] [options]
vagrant@vagrant-ubuntu-trusty-64:~$ npm update --help
npm update [pkg]

I'm really hoping we can get some equivalent of gem/npm/bower install --save

What would this do in a nutshell? E.g.: what would a pip install --save look like?

That and at a systems level, the fact that dependencies are duplicated for
libraries between requirements.txt and the setup.py

I think @dstufft would say that you can either omit the requirements.txt (since you said libraries) or you can put -e . in your requirements.txt, as mentioned in the excellent blog post: https://caremad.io/2013/07/setup-vs-requirement/

[dstufft]

Accidentally closed this, reopening. Sorry!

[BrownTruck]

Hello!

As part of an effort to ease the contribution process and adopt a more standard workflow pip has switched to doing development on the master branch. However, this Pull Request was made against the develop branch so it will need to be resubmitted against master.

If you do nothing, this Pull Request will be automatically migrated by @BrownTruck for you.

If you would like to retain control over this pull request then you should resubmit it against the master branch, closing and referencing the original Pull Request.

If you choose to migrate this Pull Request yourself, here is an example message that you can copy and paste:

see also: #59

---

*This was migrated from pypa/pip#313 to reparent it to the ``master`` branch. Please see original pull request for any previous discussion.*

If this pull request is no longer needed, please feel free to close it.

[BrownTruck]

This Pull Request has been automatically migrated to #3744 to reparent it to the master branch. Please see the new pull request for any new discussion.