Python3 -m pip install --user broken in debian testing

I’m seeing this in debian testing aka bookworm:

$ python3 -m pip install --user colour-text
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

This look wrong to me as I am not installing into the systems site-packages.


There’s a very long thread about this already; it’s a side effect of a change which was made on purpose. While you aren’t installing into the system site-packages, you are installing into a directory which can be seen by the distribution’s Python installation, so the effect is similar.

I have been spoilt by Fedora using -s for its installed python apps that means that using pip install --user is safe.

I will have to figure out how to build a venv that is as convient to use and maintain as pip install --user is.

What’s -s? Not seeing it in the pip install --help output.

It’s worth noting that even sudo pip install was reasonably safe on
Debian since ages because it patched pip to install into /usr/local
while distro package installed into /usr, things only ever got dicey
if you needed different versions of a library via pip than were
installed from debs, and couldn’t uninstall them because of
interdependencies from other required system packages.

By comparison, Red Hat distros (at least until recently) were where
you ended up with libs from RPMs and pip going into the same
directory and silently overwriting each other’s files.

Its the Python -s option. Not a pip option.
That tell python to not add the users site package to the python path.
Thus making user package unable to break a system install python app.