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 a "Upgrade all local installed packages" #313

Closed
wants to merge 1 commit into
base: develop
from

Conversation

Projects
None yet
10 participants
@jedie

jedie commented Jul 7, 2011

see also: #59

@jezdez

This comment has been minimized.

Show comment
Hide comment
@jezdez

jezdez Jul 8, 2011

Contributor

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.

Contributor

jezdez commented Jul 8, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tkruse

tkruse Apr 3, 2012

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

tkruse commented Apr 3, 2012

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

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode May 13, 2012

Contributor

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)

Contributor

qwcode commented May 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tkruse

tkruse Jul 13, 2012

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

tkruse commented Jul 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jul 13, 2012

Contributor

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.

Contributor

qwcode commented Jul 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@corydolphin

corydolphin Dec 16, 2012

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

corydolphin commented Dec 16, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Dec 17, 2012

Contributor

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

Contributor

qwcode commented Dec 17, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@employ

employ commented Feb 13, 2013

+1

@clarkevans

This comment has been minimized.

Show comment
Hide comment
@clarkevans

clarkevans Jun 18, 2013

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.

clarkevans commented Jun 18, 2013

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

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 5, 2015

Contributor

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?

Contributor

msabramo commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@corydolphin

corydolphin Mar 6, 2015

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

corydolphin commented Mar 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 6, 2015

Contributor

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/

Contributor

msabramo commented Mar 6, 2015

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 dstufft closed this May 18, 2016

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft May 18, 2016

Member

Accidentally closed this, reopening. Sorry!

Member

dstufft commented May 18, 2016

Accidentally closed this, reopening. Sorry!

@dstufft dstufft reopened this May 18, 2016

@BrownTruck

This comment has been minimized.

Show comment
Hide comment
@BrownTruck

BrownTruck May 19, 2016

Contributor

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.

Contributor

BrownTruck commented May 19, 2016

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 comment has been minimized.

Show comment
Hide comment
@BrownTruck

BrownTruck May 26, 2016

Contributor

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.

Contributor

BrownTruck commented May 26, 2016

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.

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