root warning is spurious in single purpose pyenv pythons meant for root apps

[jettero]

In our test kit we use pyenv in a Docker to load a set of pythons and do various things. None of them are really system pythons, so the relatively recent orange warning, "WARNING: Running pip as root will break packages and permissions. You should install packages reliably by using venv: https://pip.pypa.io/warnings/venv" is a little vexing.

It's a minor irritation for sure. But, if I have 6 or 7 single purpose pythons installed, why do they technically need to be virtualenv to be a virtual environment? There should be some other way to quiet this warning or detect that it's not in /usr/ prefix or something.

I'm perfectly willing to submit a PR, but I can't decide if it should be an env var, a command-line switch, some sort of pyenv detector, a /usr/ prefix detector, or some other thing I haven't thought about.

I also can't tell if such a thing would be welcome. Thoughts?

[uranusjr]

Even if you’re in a container, it is still best practice to avoid running as root.

[jettero]

agreed, but the app runs as root and pretty much needs to run as root, so ... we run it as root

[pfmoore]

Fair point, but you said it yourself, it's a minor irritation. I feel that an option to disable this warning would be used more by people who think they are OK to ignore the advice and are wrong, than by people who genuinely are in a situation where it's OK. So even though it might be a benefit for you, I feel that such a PR would be a net loss for the pip user community as a whole, I'm afraid.

BTW, you could quiet the warning by wrapping pip in a little script - excuse my lack of Unix knowledge

pip $@ | grep -v "WARNING: Running pip as root will break packages and permissions"

(That pipe probably needs to be on stderr not stdout, but that's definitely beyond my Unix level!)

[jettero]

On the other hand, literally every python I install in a pyenv situation is a virtual-env. I don't think it's fair to call any of them system pythons even if they're running as root. It's orange and has the shouty pontificating warning. I feel like I'm being yelled at by someone that doesn't undestand the use case.

[jettero]

The flip side is really, why is it ok to run pip as root in a virtualenv and not in a pyenv?

[pfmoore]

The flip side is really, why is it ok to run pip as root in a virtualenv and not in a pyenv?

No reason, really. It's just that the default install location in a virtualenv is safe. But you could run pip install --prefix from a virtualenv and wreck your system.

Ultimately, the problem is that we're trying to firefight a genuine, real-life issue where people were using sudo pip install - and worse still, were advising others to do that - and wrecking their systems. And then pip was getting the bad press - "pip wrecked my OS". So we try to warn them when they do this. Most people probably still do it, but at least now we can point out they were advised not to 🙁

Adding more options doesn't help - if people can't accept the message that you shouldn't use sudo unless you know what you are doing, why would they be any more likely to stop just because they had to add an extra flag --suppress-root-warning?

To be honest though, I don't really care that much. I don't use Unix much, and when I do, I don't use pip as root. All I care about personally is keeping pip's messaging on this matter simple.

[jettero]

Yeah, I totally get that. It's one of the very first things you point out to a new SRE (or sysadmin or whatever): don't mess with the system python.

I'm not saying the warning shouldn't be there. I'm saying we should be able to suppress it when it's wrong, which is literally every time it's not the actual system python tracked by the system package manager.

What if I was running a root program to rename users or something, and I was running it from a user python in /root/mah-python/bin/python3.7.9 ... this pip is going to complain I'm not using a virtualenv, but ... I mean, I totally am. It's just my very own python.

There's actually lots of programs that run very appropriately as root and I personally install a brand new python for most of them using ansible or chef or whatever (the system python is often a few versions behind, or I may need a very ancient version for some application or another).

Suddenly, all my scripts are complaining very loudly when I install modules via pip because I don't use a virtualenv for the app... I generally install a whole python (with its own compile time flags and versions) for it.

Again, this is a minor thing, but I don't fully see the benefit of this warning anyway. It's something junior admins are going to screw up for the rest of time. It doesn't really save anything. I understand the motivation, but it just seems silly to make this half-effort guess at the user's intentions and then not provide a way to quite it back down when it's wrong.

[uranusjr]

Honestly I don't see the benefit of arguing over the message. You know what you're doing, just ignore it and move on. Is there any practical downside of it being there?

[uranusjr]

I thought about this a bit in context of the work-in-progress EXTERNALLY-MANAGED flag. (WARNING: Still an early draft and can still change drastically.)

As it currently stands, the Python stdlib will gain a new configuration file EXTERNALLY-MANAGED that disables global pip (un)install, and pip (un)install will grow a --dangerous option (name TBD so we can't implement it just yet) to override that. We shouldn't show the root warning when --dangerous is passed, so we can likely reuse that option to a non-EXTERNALLY-MANAGED prefix (e.g. pyenv-compiled Python) as well.

I'll try to keep this use case in mind when working on EXTERNALLY-MANAGED to keep this trait working if possible.

[aebrahim]

It's worth noting that this spurious message occurs when using the official python:3.8 docker image. I think it would be helpful if it was at least opted out there - even if a root user in the container not best practice, it's what the official image is doing.

[pradyunsg]

Please feel free to take that up with whoever provides the docker image.

Honestly, right now, this is a minor annoyance to an informed expert user, while being fairly useful at providing context for new users. I think it's a worthwhile tradeoff here basically.

[uranusjr]

It shows in the python:3.8 image if you run as root. The warning is advising against running pip as root, which applies whether an installation is in a Docker image or whether it is official or not. I don’t see why the python images should do anything different.

[Sekuraz]

@uranusjr So you do expect someone to not install packages as root which are supposed to be used and found system wide within my container?
The only solution I can think of is

1. Change to a non root user (under witch all subsequent code has to run, even if it needs root privileges like ports etc.)
2. Create a virtual environment which all other people have to use
3. Use pip there

The problems are, that this approach is complicated and error prone and requires a lot more documentation than adding a flag to pip to silence this warning.
In this sense I'd like to remember the readers about the Zen of python, especially

Errors should never pass silently.
Unless explicitly silenced.

We don't need to argue that pip install as root is most likely an error. But not always.

[pradyunsg]

You are a user who knows what this warning means, knows why it doesn't affect your workflow and also has enough expertise to know why it is being presented. Chances are, so do most people who see this warning in docker containers. If they don't, then they will learn about the risks and determine for themselves if it is an issue.

If it's not a problem in your use case, fine, it's a warning. You can ignore it, if you think you know better. We want to protect our users who don't. I will note that we've seen exactly 3 users interact with this and that's way less than what we'd see if this was really a problem for pip's users.

I don't think there is a way to make it possible for experienced users to not see this warning while also making sure that it serves the purpose of getting inexperienced users to understand that they should not do this in general.

And, yes, there is a cost of adding a flag for this. I've authored most of the --no-warn-blah-blah flags in pip and I don't think that is acceptable in this case -- the whole reason we've added this warning is to make sure that uninformed users see it and that it serves as a trigger for them to be informed better. Making it possible for those users to hit advice of "oh, just add this and never see it again" (especially as a top-voted answer from a largely expert audience) makes it too easy for such users to take an approach we don't want them to take; defeating the whole reason this warning has been added.

This has been discussed at length over many years in many places. I don't think we're adding anything to the discourse at this point. Others are free to discuss this, but I'm gonna close this issue now.

[jettero]

this is still really annoying. I don't see any downside to allowing people to opt out of the warning via environment variable or switch or something.

[jettero]

I just started using colab.google.com ... it's the easiest way by far to run tensorflow ... and the whole thing runs as root so pip is complaining in giant yellow letters WARNING YOU DON"T KNOW HOW TO USE COLAB STUPID...

but the bug is actually in pip.