Override PIP_USER if running_under_virtualenv

[jonathonf]

This PR sets an environment variable to override any PIP_USER setting when being used within a virtual environment which sets a VIRTUAL_ENV environment variable.

This works around issues such as #2081, #4141 and #5702 .

It's a pretty naive solution, and I've tested only under Linux so this may be an incomplete solution for macOS/Windows.

[chrahunt]

Hello! From the latest comment by @pradyunsg on #5702 (comment) it looks like the intent is to make this an error.

[jonathonf]

I don't know if there is more to it, but from reading the other issues it appears it going to be made an error because --user doesn't work within a virtual environment.

As far as I can tell this change works around the incompatibility of having a --user setting in a pip.conf and using a virtual environment, so if there aren't any non-obvious side-effects this should be a better option.

[chrahunt]

There's a couple, based on reading #5702:

1. A user providing --user on the command-line would get unexpected behavior
2. A user providing PIP_USER=yes in their environment would get unexpected behavior

We want to provide the ability to have the desired behavior (use virtualenv if in virtualenv, use user if not), but the UI/UX around it is important otherwise we end up with issues and user confusion/frustration.

[jonathonf]

Adding PIP_USER=yes within the environment would be the equivalent of setting global.user=yes in a configuration file so I don't think that would cause too much confusion, and given PIP_USER=yes would currently cause an issue within a venv anyway then effectively ignoring that variable in a context it makes no sense to be used in keeps things working.

As for --user within a venv... I'd argue that it's implied that a venv is a "user-type" environment so using --user is nonsensical and so it should be a no-op (same as other commenters in the other issues).

In any event, this change makes behaviour incrementally less unexpected than the current state.

we end up with issues and user confusion/frustration

I'd say this is already the case, and has been since at least 2014. 😉

[chrahunt]

We would also need tests for this, but I'm not sure it's worth doing until other people weigh in and can confirm this is a good approach that we want to take while working towards that other issue.

[jonathonf]

I'm not sure it's worth doing until other people weigh in and can confirm this is a good approach that we want to take while working towards that other issue.

I can understand the rationale. I'm just also aware that this has been "open" since 2014 and it doesn't appear that any progress has been made, and that sometimes "something is better than nothing".

Another approach is over here: #7002

until other people weigh in

Is there any way of poking other people who could weigh in? Even if this particular PR is no good it might trigger some ideas.

[pradyunsg]

I am not sure whether we want to go down this route, but the way this is implemented currently is definitely not how we'd want to implement this.

I'd rather we amend the current check for aborting:

diff --git a/src/pip/_internal/commands/install.py b/src/pip/_internal/commands/install.py
index 66071f6e..bb97dbbb 100644
--- a/src/pip/_internal/commands/install.py
+++ b/src/pip/_internal/commands/install.py
@@ -298,10 +298,11 @@ class InstallCommand(RequirementCommand):
                     "different installation locations"
                 )
             if virtualenv_no_global():
-                raise InstallationError(
-                    "Can not perform a '--user' install. User site-packages "
-                    "are not visible in this virtualenv."
+                logger.info(
+                    "Ignoring '--user', since user site-packages are not "
+                    "visible in this virtualenv."
                 )
+                options.use_user_site = False
             install_options.append('--user')
             install_options.append('--prefix=')

[pradyunsg]

I've filed #7164 for discussion on this functionality.

[BrownTruck]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will be eligible for code review and hopefully merging!

[pradyunsg]

Closing since #7002 has merged.