Using --root option checks existing installation in global site-packages (instead of given dir)

[asfaltboy]

For instance, if I have no requests package installed globally, running pip install --root=$DIR requests==2.7 installs the package into $DIR/usr/lib/python27/site-packages; and subsequent re-runs do the same even when the package exists.

Alternatively installing requests globally prevents --root from ever running, returning the familiar Requirement already satisfied message pointing at the global site-packages (for me, on OSX it shows /usr/local/lib/python2.7/site-packages).

By the way, --no-use-wheel does not seem to have an effect on this.

[sigmavirus24]

I can confirm this behaviour. That said, I traced how we use --root and what we effectively do is pass that to setuptools which means that this is a setuptools bug. Please file it there. /cc @dstufft

[flying-sheep]

i tried to do pip install --root=... some-wheel-file.whl, which failed with a permission error because it tried to uninstall a globally installed version(!) and i luckily didn’t run with root permissions.

if i had, pip would have fucked up my package-manager-controlled global install.

is this the same bug?

---

i can circumvent it by doing --root=... --ignore-installed --no-deps, but that is a hack:

what it does is ignoring installed packages to make it not try to remove previously installed versions (which it shouldn’t do in the first place if those versions don’t live in the specified --root!), and then i make it not install dependencies so that i end up with only that package installed in my --root.

what should happen is the same as with --user: install all dependencies to --root, then check if the package itself is installed in --root, remove it if so, and (re)install it to there. leave it alone if it’s installed elsewhere

[asfaltboy]

@sigmavirus24 I got a bit lost following the code in setuptools/distutils ... should I just open the issue here and describe the trouble I have with pip ?

[sigmavirus24]

@flying-sheep I don't think it's the same bug.

@asfaltboy I chatted with @dstufft about this. He isn't as confident as I am that this is a setuptools problem. I would still open the issue on setuptools on the chance that I'm right. I might dive back into this today to be 100% certain it isn't pip, but the only mention of --root I found led me to setuptools.

[asfaltboy]

I don't think that the behaviour of --root during setup itself is an issue, rather the extra prep work done by pip is slightly inconsistent:

1. I found that running python setup.py install --root=$DIR directly always behaves the same, it install the package under $DIR/usr/lib/python27/site-packages, and does not (seem to) check if the package already installed. This means that the first "part" of my issue description above, i.e install always ignores existing package even if in $DIR, performs the same as setup.py, for better or worse.
2. Now for the second part, i.e pip reports package is already installed globally. Tracing through calls with pdb lead me to a call to InstallRequirement.check_if_exists which subsequently aborts the install, since the package is found on sys.path.

I feel that pip behaviour should at least be consistent in both cases, and it may be simplest to skip "requirement exists" test if root is passed (see entry point into RequirementSet.prepare_files).

However, personally, I think it would be more useful to temporarily have sys.path use target root $DIR (only?) so that all requirements tests run only for that location; with the intention of making --root in line with other pip functionality. However, I'm not sure of the full consequences of this.

[dstufft]

Closing this as a duplicate of #3063.