Re: Pip installs to unexpected place
On 4/15/2025 5:38 PM, rbowman via Python-list wrote:
On Tue, 15 Apr 2025 14:12:19 -0400, Thomas Passin wrote:
On Linux, at least, it's standard for pip to install into the user's
site-packages location if it's not invoked with admin privileges - even
without --user. Pip will emit a message saying so. Well, that used to be
true but nowadays Pip wants you to use the --break-system-packages flag
if you want to insist on installing into the system's Python install,
even if it's going to go into --user. I'm not sure if the restriction
will be in place given that the OP built his own Python version.
Is that pip or a distro's version of pip? On Fedora I get the message
about defaulting to user. On Ubuntu I get a message to use a venv or if I
really want a global install to use something like 'pip install python3-
black'. Ubuntu's is pip 24.2, Fedor's is 24.3.1 but neither of them show
'--break-system-packages' in --help.
The behavior is specifed in
https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments
Exactly how pip works and what messages it emits are specified by this
document, and the details depend on how the distro's packagers configure
it. For example, here is a bit of the spec:
"Before a Python-specific package installer (that is, a tool such as pip
- not an external tool such as apt) installs a package into a certain
Python context, it should make the following checks by default:
Is it running outside of a virtual environment? It can determine
this by whether sys.prefix == sys.base_prefix.
Is there an EXTERNALLY-MANAGED file in the directory identified by
sysconfig.get_path("stdlib", sysconfig.get_default_scheme())?
If both of these conditions are true, the installer should exit with an
error message indicating that package installation into this Python
interpreter’s directory are disabled outside of a virtual environment.
The installer should have a way for the user to override these rules,
such as a command-line flag --break-system-packages. This option should
not be enabled by default and should carry some connotation that its use
is risky."
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On Tue, 15 Apr 2025 14:12:19 -0400, Thomas Passin wrote: > On Linux, at least, it's standard for pip to install into the user's > site-packages location if it's not invoked with admin privileges - even > without --user. Pip will emit a message saying so. Well, that used to be > true but nowadays Pip wants you to use the --break-system-packages flag > if you want to insist on installing into the system's Python install, > even if it's going to go into --user. I'm not sure if the restriction > will be in place given that the OP built his own Python version. Is that pip or a distro's version of pip? On Fedora I get the message about defaulting to user. On Ubuntu I get a message to use a venv or if I really want a global install to use something like 'pip install python3- black'. Ubuntu's is pip 24.2, Fedor's is 24.3.1 but neither of them show '--break-system-packages' in --help. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-16, Mats Wichmann via Python-list wrote: > On 4/15/25 16:07, Grant Edwards via Python-list wrote: >> On 2025-04-15, Thomas Passin via Python-list wrote: >> >>> On Linux, at least, it's standard for pip to install into the user's >>> site-packages location if it's not invoked with admin privileges - even >>> without --user. Pip will emit a message saying so. Well, that used to be >>> true but nowadays Pip wants you to use the --break-system-packages flag >>> if you want to insist on installing into the system's Python install, >>> even if it's going to go into --user. >> >> I've always been a little baffled by that message when installing with >> --user. How can that possibly break system stuff? > > Your user install dir is in your python path, so when you go to run an > installed Python program which imports other packages, it might pick up > the version you have in your user space rather than the system one it > was tested with. Yes, I understand that. But that's breaking stuff for the user not for the system. Of course installing stuff for the user can break stuff for the user. I don't need a warning to tell me that. Also... when installing stuff with pip --user, it is always a package that is not installed for the system (usually not even available for the system). How can that "break system packages"? -- Grant -- https://mail.python.org/mailman/listinfo/python-list
