-
-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
ensurepip has no --break-system-packages option #118384
Comments
I suspect ensurepip should not pass this message on from pip. @pfmoore Are you involved with ensurepip? |
I think the situation is a little more complex than that, unfortunately. Unless you pass the However, I'm a little unclear about the scenario here. Normally, So I think I'd want to know more about why the user is running |
It's beside the point - regardless of how I use Python the error message shouldn't tell me to do something I can't do. Since I'm unhappy with how my OS vendor has decided to package Python, Haskell, and other language's runtimes I want to manage them myself. This I do by installing pip in ~/.local/bin which works perfectly fine (or at least used to). "We're all consenting adults here" and I want to continue with my workflow. |
You can use pip (with the I agree that the message is a bit misleading - if someone was motivated, they could look at the possibility of creating a PR that suppressed the one line "You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages." from the pip output, simply failing without suggesting that option. But to avoid this becoming a maintenance burden, it would need to be done in a way that didn't require updating whenever pip changed the wording of that message - and that's likely to be more work than it's worth, given that the benefit is relatively minor. |
I'm getting a new error message from python -m ensurepip --upgrade now:
I used ensurepip because the documentation recommends it: "The ensurepip package provides support for bootstrapping the pip installer into an existing Python installation or virtual environment. This bootstrapping approach reflects the fact that pip is an independent project with its own release cycle, and the latest available stable version is bundled with maintenance and feature releases of the CPython reference interpreter. In most cases, end users of Python shouldn’t need to invoke this module directly (as pip should be bootstrapped by default), but it may be needed if installing pip was skipped when installing Python (or when creating a virtual environment) or after explicitly uninstalling pip." I didn't know about get-pip.py. |
I asked on the PEP 668 (externally managed environments) discussion thread what the PEP authors thought about this situation: https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/10302/117 |
Wow, thanks for the work you do! |
get-pip.py requires downloading and running some code from the internet which isn't verified or trivially verifiable. And pip doesn't have to be used with pypi.org (or indeed for downloading wheels from the internet) so the fact that it can't cryptographically verify the authenticity of a pypi package before installing it, isn't necessarily a reason to say that it's no different from get-pip.py Besides: ensurepip is a public, and publicly documented, module. It's not obvious to me that it isn't for general use. It's being used here for precisely its documented purpose.
But neither of these are the case. In fact, https://pip.pypa.io/en/stable/installation/ goes out of its way to list ensurepip as one of the ways to "officially" install pip, in addition to get-pip.py. In other words, pip directly encourages end users to run ensurepip, as an end user tool. ... I don't think it makes sense to declare ensurepip as something not for general use. And if it's for general use, then it should support the flag it tells you to use to make sure it works. |
Additionally, ensurepip supports the --user flag, which is clearly not intended for use by the preinstallation process, nor is it intended for use by venvs.
Its sole use is to do precisely as the OP wants: disregard the choices of the OS vendor, and install pip to ~/.local/bin / ~/.local/lib/python3.XX/site-packages. |
Note that the requirement to use To be 100% clear, the OP hasn’t said how they built their copy of Python. It seems to me very odd that a user-built Python installed into |
I'm not sure how you concluded that python is installed to ~/.local/bin just because the OP is attempting to install pip there. The OP was very clear that it is not a user-built python.
|
Apologies, I misread the comment as saying that they had installed python in But I'm now even more confused, as I don't see how The OP originally said:
My response was yes, the message is not ideal and could be changed, but it's non-trivial to do so. If someone wants to raise a PR for that, we can thrash out the details in that PR. I do not think @eli-schwartz do you have an actual, reproducible issue where you are seeing this error, or are you simply arguing principles based on the OP's original report? Because I got the impression that the OP was happy with the original response (@bjourne if you do still have an issue here, please feel free to say so - I don't want the current discussion to distract from making sure you have a solution you are happy with). |
Ensurepip bundles a copy of pip, and injects itself into the path so that it can import pip and use pip to install a pip wheel. Pip itself contains the functionality for automatically assuming --user when you run its installation procedures. So running This is an important and often forgotten-about safety feature of pip. My personal opinion is that it was prescient, and rendered EXTERNALLY-MANAGED unnecessary, but clearly not everyone agrees...
Because pip has another implemented functionality, to require --break-system-packages (a flag that claims you're breaking the packages in the global site-packages) even when used with --user to operate on the user site-packages. I think this functionality is unhelpful, but I don't make the rules of pip.
That argument equally applies to pip. If the OS vendor has marked the location (that is to say, has marked So why does pip have an option to override the vendor's choice, but ensurepip doesn't?
I'm seeing the exact same error as the OP. I tried running Yes, I went out of my way to verify it again with --user passed to ensurepip, even though it's the default pip functionality.
The OP responded to you saying you've asked on the python help forum, what others think -- by saying thanks for all the work you do. I don't see anything there to suggest "happy with the original response" -- quite the contrary, my implicit understanding was that the OP is happy with your willingness to reconsider the matter by asking for further input from the PEP authors, and is awaiting a status update. |
I have not.
For pip, --user is not required to install in ~/.local so I didn't think it would be required for ensurepip either. Regardless --user doesn't work either.
Fair but
No, get-pip.py solved it. Note: I prefer it like this because for students with no root access and limited home directories installing python packages in |
When not run as the owner of the Python installation. It's worth remembering that the
But I don't want to nitpick here. Docs can be changed, what matters is making sure people understand the right way to use the module, and don't have unreasonable expectations.
My apologies, I'd forgotten that subtlety. The reason is the same as all aspects of PEP 668 - installing to user-site can shadow critical system functionality, and distributors, not unreasonably, want to be able to restrict the chance of that happening because a user didn't understand the implications of what they were doing. You're welcome to disagree with that reasoning (as a Windows user, I can't say I like the way Linux distros do things like this, but that's just my viewpoint) but it is what was agreed in the PEP.
Because (as I understand it) ensurepip is intended to be used by the people managing the Python installation, not by users of that installation.
OK, and my response is the same: yes, the message is not ideal and could be changed, but it's non-trivial to do so. If someone wants to raise a PR for that, we can thrash out the details in that PR.
Feel free to check the linked discussion, and participate there if you want. So far, the only response has been from Debian, who basically said they only use I don't think there's anything further to say at the moment. The message can be changed if anyone is interested in putting in the work to do so. The docs can be changed to more explicitly discourage this sort of use of If the discussion thread results in a different consensus, I'll report back here and we can proceed based on whatever that consensus is. Footnotes
|
I just realized that get-pip.py does not solve my use case because I have to re-run the script every time I |
Bug report
Bug description:
So it needs the
--break-system-packages
option or the error message should not tell me to use it.CPython versions tested on:
3.12
Operating systems tested on:
Linux
The text was updated successfully, but these errors were encountered: