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

just log warnings when --user installs hide behind virtualenv installs #1443

Closed
qwcode opened this issue Jan 9, 2014 · 5 comments
Closed
Labels
auto-locked Outdated issues that have been locked by automation C: user scheme Handling of packages in user-specific directories type: enhancement Improvements to functionality

Comments

@qwcode
Copy link
Contributor

qwcode commented Jan 9, 2014

currently, users can fail with Will not install to the user site because it will lack sys.path precedence when doing --user installs that will be hidden behind virtualenv site packages (in virtualenvs with system access, the precedence is virtualenv, then user, then global).

I'm considering whether these installs should just warn in this case, and not fail.

the reason to warn (vs fail) is in the scenario, where only one dependency will fail, as part of a larger install of many packages.

@skyl
Copy link

skyl commented Jan 9, 2014

I think the optimal solution might be to add a --force or similar that will install to the location regardless of the conflict/precedence

@qwcode
Copy link
Contributor Author

qwcode commented Jan 9, 2014

this is a very special case though. not many people use --user, and even less like this.
not sure I want to add an option for it.

@skyl
Copy link

skyl commented Jan 9, 2014

the hack of all hacks that seems to be working for me right now is to have a sh wrapper around pip that seds activate_this.py to remove sys.real_prefix = sys.prefix and then after I run pip, I replace the original activate_this.py.

@skyl
Copy link

skyl commented Jan 23, 2014

Well, the above hack no longer works in 1.5.1 and I can't figure out why. I guess sys.real_prefix gets set in a slightly different way... haven't quite figured it out.

@dstufft
Copy link
Member

dstufft commented Mar 22, 2017

This has been an error for 3+ years at this point and using --user while in a virtual environment is most likely an accident. I'm going to close this as I don't think moving to a warning is going to be helpful here.

@dstufft dstufft closed this as completed Mar 22, 2017
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 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 C: user scheme Handling of packages in user-specific directories type: enhancement Improvements to functionality
Projects
None yet
Development

No branches or pull requests

3 participants