This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author uranusjr
Recipients christian.heimes, doko, mattip, piotr.dobrogost, steve.dower, uranusjr
Date 2021-03-29.20:39:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Gentle ping again :) I’ve also created a PR for this.

> The Debian/Ubuntu packages have a local patch for distutils/setuptools introducing an --install-layout option.  Maybe have the same for pip?

Pip already has a similar mechanism. The default layout is `prefix` and you can change the installation prefix with `--prefix`; `home` and `user` layouts can be specified with `--home={base}` and `--user`.

> So the problem to solve is
>  - let a "sudo pip install" fail by default on the real system
>  - let the same install succeed in a docker environment, or any other "image".

These need to be done in pip, so we’ll have a separate discussion on them elsewhere.

>  - behave transparently on venv and virtualenv installations.

This is what this issue tries to address. A distribution can overwrite `sysconfig.get_default_scheme()` and `sysconfig.get_preferred_scheme(variant)` to return the correct scheme based on whether the current Python is in a virtual environment (by detecting `sys.prefix` and `sys.base_prefix`, I think).

When in a virtual environment, it can return the same scheme as the upstream. Outside of a virtual environment, it can do whatever the platform sees fit, and pip (or whatever calls sysconfig) will install things into wherever it’s told to by the two functions.
Date User Action Args
2021-03-29 20:39:55uranusjrsetrecipients: + uranusjr, doko, christian.heimes, piotr.dobrogost, mattip, steve.dower
2021-03-29 20:39:55uranusjrsetmessageid: <>
2021-03-29 20:39:55uranusjrlinkissue43312 messages
2021-03-29 20:39:54uranusjrcreate