-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
root warning is spurious in single purpose pyenv pythons meant for root apps #10028
Comments
Even if you’re in a container, it is still best practice to avoid running as root. |
agreed, but the app runs as root and pretty much needs to run as root, so ... we run it as root |
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
(That pipe probably needs to be on stderr not stdout, but that's definitely beyond my Unix level!) |
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. |
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 Ultimately, the problem is that we're trying to firefight a genuine, real-life issue where people were using 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 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. |
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. |
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? |
I thought about this a bit in context of the work-in-progress As it currently stands, the Python stdlib will gain a new configuration file I'll try to keep this use case in mind when working on |
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. |
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. |
It shows in the |
@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 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.
We don't need to argue that |
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 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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: