Display warning when 'SUDO_COMMAND' in os.environ

[msabramo]

Because using sudo with pip is often a mistake; often people either:

• don't realize that sudo won't honor their activated virtualenv
• are trying to use pip to manage packages in their system python, which can break
  systems and is often better left to the system package manager.

This is a warning rather than a fatal error, so that it is less likely to break someone's workflow or tools.

This is inspired by:

• frequent occurrences of people on systems of ours doing source /path/to/virtualenv/bin/activate; sudo -u appuser pip install foobar and installing cruft in the system Python.
• @pfmoore's comment: Make --require-virtualenv output more info #2401 (comment)

Cc: @aconrad, @sudarkoff, @sontek

[msabramo]

Comments about this one?

I just remembered it because one of our devs just unknowingly did sudo pip install pkg, expecting it to go to the virtualenv that he had activated.

[msabramo]

Just ran into this again today. One of our devs had trouble upgrading because he apparently had previously done a sudo pip install:

 error: [Errno 1] Operation not permitted: 'panel.egg-info/requires.txt'

This would be nice to have to prevent such issues.

[sudarkoff]

As much as I'd love to see this problem fixed, I suspect that a simple warning won't cut it for a couple of reasons: 1) people ignore warnings, 2) when unsure or can't be bothered, people go with the default (which is "do nothig"). Now, clearly, a warning is better than nothing. It also could be a good first step towards a final solution, whatever that might be. For example, pip install can have a parameter to silence that warning. And the warning itself can warn the user about turning into an error some time down the road unless the parameter is use to explicitly allow sudo pip install.

[dstufft]

I'm going to close this. I don't think raising a warning, especially one this intrusive, is something we should do. Using pip via sudo is a perfectly valid use case.

[msabramo]

When is using pip via sudo a good idea?

I've done it myself on occasion on my laptop to quickly upgrade some tool I use a lot, but I've always felt dirty doing it and knew that it was risky and I should probably be using something like pipsi or something instead of risking breaking my system.

I've run into a fair amount of other people borking things by accidentally doing sudo pip install though, usually one of:

• They do . $VIRTUAL_ENV/bin/activate and then sudo pip install ..., thinking that they are installing stuff in a virtualenv when in fact they are installing stuff in the global Python and wreaking havoc on a system that is shared by many developers.
• They do sudo pip install by accident in their development tree and now files in their development tree are owned by root and now stuff breaks when they try to do stuff not as root.

Certainly if sudo pip is something valid and useful, I don't want to add an intrusive warning, but if I knew what the valid cases were, I might be able to refine the conditions under which the warning is shown.

[dstufft]

Whenever you want to install something into the global site packages that isn't available in your package manager. In Debian Jessie with the python-pip from the archives this works reasonably well. On other distros Python needs more support for proper separation of vendor vs local but it's a use case we want to make better too.

It's a bit like making sudo make install print a warning.

[msabramo]

Well some folks, like @hynek, would say "Don’t pip-install anything into its global site-packages beyond virtualenv.". But he's already made that point and probably a lot of people aren't going to follow it all the time for one reason or another.

That said, I thought of a different strategy, which is putting the warning in virtualenv instead.

pypa/virtualenv#727

That might be annoying too, but it does at least have the advantage that it only come into play if someone has activated a virtualenv which was not true of this change in pip. So this would allow folks to sudo pip install foobar to their heart's content, as long as they haven't activated a virtualenv, which to me suggests that they might've thought that sudo pip install was going to work in that virtualenv and might be surprised that it doesn't. So maybe the warning is more helpful there? Maybe not?

[msabramo]

Whenever you want to install something into the global site packages that isn't available in your package manager

Isn't that an excellent use case for pip install --user?

Are there some cases where pip install --user doesn't work? (I've personally never used it, as for some reason I never noticed it or somehow didn't think it applied to me).

[dstufft]

Yea, when you want to install something for the entire system.

[msabramo]

What if this were configurable and off by default?

[RonnyPfannschmidt]

well, unlike make install, ay pip install as superuser has the potential of completely wwreck the system package manager - and since pip has zero integration wit the os level package manager i think its very fair not to warn, but to actually ask for confirmation - because a pip install is not like a make install
a pip install does not complain about needed updates or other package installations, it *does them

prior to completely avoiding it i wrecked my system quit a few times with sudo pip install

also its not something you immediately discover, i have seen people do that, test their stuff
and go for lunch, then the rest of us discovered that their world had been broken by someone now out for an hour

[msabramo]

Or what we had happen several times is someone did this on a shared system. They thought they were upgrading packages for their app's virtualenv, but they had in fact messed up the system.

So even if it's not the default behavior, I would love a way to turn on some kind of check for this on the system level.

[msabramo]

I wonder if distro folks might appreciate this.

The fact that it works "reasonably well" on Debian Jessie suggests to me that it doesn't work well on other distros. We certainly had problems with this on Ubuntu and OS X systems. I wouldn't be surprised if sudo pip install ends up creating bogus support tickets for the distros because people inadvertently subvert their package manager and then complain to the distro when things are broken.