pip install --target still complaining about "externally managed platform".
Description
I'm trying install pypi packages system-wide for a custom platform (using docker, so no additional virtualization is needed to protect me from corrupting the system).
Reading https://packaging.python.org/en/latest/specifications/externally-managed-environments/, I understand that using an alternative --prefix value should allow me to maintain custom installations. Unfortunately, the behavior of pip --prefix is broken on Debian-based systems (https://github.com/pypa/pip/issues/10978), so I'm trying to use pip --target instead. However, no matter the value I'm passing to that, this still triggers the "externally managed environment" error.
What is the expected way for me to install pypi packages without involving virtualization ?
Expected behavior
I need a way to install pypi packages system-wide in a custom location without involving python's own virtual environments, and without having to pass --break-system-packages in each pip invocation.
pip version
24.0
Python version
3.12.3
OS
Ubuntu 24.04
How to Reproduce
sudo pip install --target foo/bar <package> will still raise an error with
error: externally-managed-environment
Output
No response
Code of Conduct
- [x] I agree to follow the PSF Code of Conduct.
ping. Can you please confirm whether pip install --target raising the "externally managed" error is expected behaviour or not, and if so, what options users have to silence it ?
Little update: it turns out running pip --target works fine, but PIP_TARGET=... pip does not. Hence it sounds like this is a bug in the handling of the PIP_TARGET environment variable, which supposedly should have the same effect as using the --target option.
Is your package an sdist or source tree or a wheel?
I'm talking about installing upstream packages, e.g. pip install -r requirements.txt into my own custom prefix (e.g. /usr/local/my-own). I'd prefer to use --prefix, but with that being buggy on Debian, the second best choice appears to be ---target. And instead of repeating that argument each time, I'd like to just pre-define the PIP_TARGET environment variable to be used by default...
I think we'd need a minimal reproducible example to understand if there's a bug here or not.
One big difference between passing a flag via the CLI or via an environmental variable is whether it is picked up by the isolated build environment, which comes into play for sdists and source trees, but not wheels.
I don't have a lot of experience with --target but I can imagine it would not work well with an isolated build environment.