bug: tox should run pip with PIP_USER=0

[anntzer]

• Minimal reproduceable example or detailed description, assign "bug"
• OS and pip list output

tox cannot use pip to install in a venv if the user has a config file that defaults to --user installs (e.g. because they (I) intend to use the distro package manager when touching distro packages) -- because pip crashes in such settings. By setting the PIP_USER environment variable to 0, tox could override that setting to force the use of in-venv installs.

Arch Linux Py3.6 (from distro) in a clean venv.
pip list

Package    Version
---------- -------
pip        9.0.3  
pluggy     0.6.0  
py         1.5.3  
setuptools 39.0.1 
six        1.11.0 
tox        3.0.0  
virtualenv 16.0.0

foo/setup.py

from setuptools import setup; setup(name="foo")

foo/tox.ini

[tox]
envlist = py36

~/.config/pip/pip.conf

[install]
user = true

Running tox yields

GLOB sdist-make: /tmp/foo/setup.py
py36 inst-nodeps: /tmp/foo/.tox/dist/foo-0.0.0.zip
ERROR: invocation failed (exit code 1), logfile: /tmp/foo/.tox/py36/log/py36-3.log
ERROR: actionid: py36
msg: installpkg
cmdargs: ['/tmp/foo/.tox/py36/bin/pip', 'install', '-U', '--no-deps', '/tmp/foo/.tox/dist/foo-0.0.0.zip']

Can not perform a '--user' install. User site-packages are not visible in this virtualenv.
Exception information:
Traceback (most recent call last):
  File "/tmp/foo/.tox/py36/lib/python3.6/site-packages/pip/_internal/basecommand.py", line 228, in main
    status = self.run(options, args)
  File "/tmp/foo/.tox/py36/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 218, in run
    "Can not perform a '--user' install. User site-packages "
pip._internal.exceptions.InstallationError: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

py36 installed: foo==0.0.0
_____________________________________________________________________________________________ summary ______________________________________________________________________________________________
ERROR:   py36: InvocationError for command /tmp/foo/.tox/py36/bin/pip install -U --no-deps /tmp/foo/.tox/dist/foo-0.0.0.zip (see /tmp/foo/.tox/py36/log/py36-3.log) (exited with code 1)

[obestwalter]

HI @anntzer, thanks for the detailed report. I am not sure if this needs or should be added to tox. This does not seem to be a common problem.

For setups that need this, the variable can be set directly in tox.ini like:

...

[testenv]
setenv = PIP_USER=0

...

(docs)

[anntzer]

Well, that would mean that literally every project using tox "should" set this variable as they could be cloned by contributors who do have this setting.
While the problem may be uncommon, the possibility of defaulting to --user is a perfectly well documented feature of pip.

[obestwalter]

Which public project are we talking about? I am asking because there are tons of public projects using tox and of all the ones on Github 4 projects have this set:

https://github.com/search?l=INI&q=PIP_USER%3D0&type=Code

So maybe this would be a feasible solution for your project after all, if contributors complain about this problem?

I am not actively against adding this to the default, if it really makes sense, but I don't know enough about this yet and really don't know if it is a sensible default for most users. So I would be interested to hear other opinions about this.

The solution for your problem, might be a new problem for somebody who has been using tox without this default until now, you know? 🤷‍♂️

[anntzer]

Your search itself shows that projects using tox had to repeatedly rediscover the need to set PIP_USER to false to get a portable tox.ini (in my specific case, I am a dev for matplotlib).
I have shown you a case where this setting is indeed needed. I cannot show you a case where it would be harmful simply because I truly cannot think of one (except of course if some unrelated program happens to also try to read that same environment variable, but that's not a particularly interesting case).

[gaborbernat]

I agree we should set to zero by default unless explicitly overridden by the user or specified in passenv. @anntzer want to open a PR for this?

Thank you for reporting the issue!

[obestwalter]

I am still not sure about this and haven't heard anything yet, why hard coding that value as default is the best way to deal with it. It does sound reasonable, if it solves the problems of the folks using this setting in their config and if it doesn't cause problems for the rest of us, but I simply don't know.

This issue is also touching on a larger one, that has to do with the introduction of environment isolation in 2.0. I was not involved in the project when that was introduced, so I am not aware of the reasoning behind this (maybe there is something in the issues about this, but the changelog does not provide any reasoning for the decision to make this the default rather than opt-in). What I noticed though is a constant trickle of issues that had to do with this change and that lead to a growing number of env vars being passed through by default to solve these problems - especially on Windows:

tox/tox/config.py

Lines 593 to 618 in 023eef3

	passenv = {"PATH", "PIP_INDEX_URL", "LANG", "LANGUAGE", "LD_LIBRARY_PATH"}
	# read in global passenv settings
	p = os.environ.get("TOX_TESTENV_PASSENV", None)
	if p is not None:
	env_values = [x for x in p.split() if x]
	value.extend(env_values)
	# we ensure that tmp directory settings are passed on
	# we could also set it to the per-venv "envtmpdir"
	# but this leads to very long paths when run with jenkins
	# so we just pass it on by default for now.
	if tox.INFO.IS_WIN:
	passenv.add("SYSTEMDRIVE") # needed for pip6
	passenv.add("SYSTEMROOT") # needed for python's crypto module
	passenv.add("PATHEXT") # needed for discovering executables
	passenv.add("COMSPEC") # needed for distutils cygwincompiler
	passenv.add("TEMP")
	passenv.add("TMP")
	# for `multiprocessing.cpu_count()` on Windows (prior to Python 3.4).
	passenv.add("NUMBER_OF_PROCESSORS")
	passenv.add("PROCESSOR_ARCHITECTURE") # platform.machine()
	passenv.add("USERPROFILE") # needed for `os.path.expanduser()`
	passenv.add("MSYSTEM") # fixes #429
	else:
	passenv.add("TMPDIR")

This gives me the impression that it might be worth thinking about that decision again and maybe head for switching the default around after a deprecation period rather than adding more and more env var special casing. A tox.ini would have to explicitly opt-in to env var isolation then, instead of silently swallowing all the env vars, especially when many of them are essential.

I know that this is completely beyond the scope of this issue, but I wanted to share my thoughts why I am a bit more sceptic about just adding another env var special casing that solves another specific env var related problem of a specific group of users. Especially because this time it would be an explicitly hard coded override rather than just passing through the wish of the user.

At the moment I would rather lean to to passing PIP_USER through to the underlying environment (and check what else we should pass through from the PIP_* family of env vars, if there are more). Simply because this would be more in line with what we already do with the other env var special casing. It should also be documented then, that if a user forces --user installs globally in their config, they will have to call tox with PIP_USER=False.

[gaborbernat]

I'm not sure I agree. All those arguments passed have a really good reason to be passed in and has mostly to do with the fact that we use pip (which then uses setuptools) to build/install packages. pip and setuptools do use a few environment variables to control their work logic, and makes sense to pass those along (as we have both pip hardcoded). Note that the list might and is completely different by the underlying build/install tools. E.g. conda uses something different, and that plugin might add just some env vars to ensure the plugin works as expected: isolated and in the virtual environment mode. I think the whole scope of tox is to work out of box in isolated environments, with minimal config. Installing packages in the user site go against tox's policy, and therefore setting that env var by default to false makes sense.

[obestwalter]

Hey @gaborbernat, I think you misunderstood me. I meant it the other way around. I mean that it might be a better way forward to reverse the default in tox to not isolate environments at all - which means that passenv=* would be the implicit default. I think many users (especially newcomers) are confused about this isolation as default and it has a lot of ripple effects (e.g. codecov/codecov-python#151). I think we should reconsider this, because of this.

I would class environment var isolation as an advanced feature that should be deactivated by default.

Anyway ... sorry for hijacking this issue, I basically just tried to explain why I was not very welcoming in accepting the next env var related special casing, because of these thoughts. Just ignore me here and deal with the problem at hand - if you two know your way around this behaviour and see no problems in adding this, just go ahead. I will open an issue later on about the broader issue. 😄

[gaborbernat]

I think the isolation offers lots of value for people; and makes reproducible tests so much easier. That codecov example is an application use case, and that documentation should specify it as you marked in in the PR. Most of the env vars we whitelist are whitelisted either because we want to increase isolation, or that we need those because we depend on them (e.g. having path for command discovery).

[asottile]

maybe a better solution would be PIP_CONFIG_FILE={}'.format(os.devnull)? (though I can already think of a situation where that might be undesirable: if an organization wanted to use that to enforce a pypi index they'd suddenly be back to public pypi)

[anntzer]

If we're trying to keep a minimal list of environment variables that do need to be set:

• there's PIP_USER=0 (because --user makes testenv creation impossible, as mentioned above)
• there's also PIP_NO_DEPS=0 (because --no-deps likely makes testenv creation incorrect, e.g. it leads to pytest being installed without its dependencies).

(Why do I have PIP_NO_DEPS set to 1 by default? Because I don't particularly like pip's dependency resolver (or lack thereof), and would rather rely (in normal cases) on my distro package manager's, which is much superior. Not that this is particularly relevant.)