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

Do not uninstall package on upgrade if new version is not to be installed in the same location #4840

Closed
NiklasRosenstein opened this issue Nov 4, 2017 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@NiklasRosenstein
Copy link

If you install a module with --user --upgrade, and the same module is already installed in the global package site, Pip first attempts to uninstall the module. I think that it should not do so unless the target install directory is the same as the previous module's version install directory.

This can be reproduced with (tested on Windows):

$ pip install six==1.10.0 --upgrade  # an old version of six
$ pip show six
$ pip install six --user --upgrade
$ pip show six

I think that in this case, the six==1.10.0 should be left untouched and the newest version of six should simply be installed to the user package directory.

@NiklasRosenstein NiklasRosenstein changed the title Do not uninstall module on upgrade if new version is not to be installed in the same location Do not uninstall package on upgrade if new version is not to be installed in the same location Nov 4, 2017
@NiklasRosenstein
Copy link
Author

The --ignore-installed option works around this issue, but if the module does not need to be upgraded, you may as well just use the package from the global package site instead of reinstalling the same package into the user site.

The issue also appears with the --target or --prefix option.

@pradyunsg
Copy link
Member

This is the problem that implementing #4575 would address. :)

@pradyunsg
Copy link
Member

@NiklasRosenstein if this issue would be resolved as a part of #4575, it'd be nice if you close this issue.

@pradyunsg pradyunsg added the S: awaiting response Waiting for a response/more information label Nov 4, 2017
@NiklasRosenstein
Copy link
Author

Yes, I think this issue should be resolved as part of #4575. :)

@pradyunsg pradyunsg removed the S: awaiting response Waiting for a response/more information label Nov 5, 2017
@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
Projects
None yet
Development

No branches or pull requests

2 participants