The “partial” scheme here would include all the necessary keys to install wheels. It would provide
If we have a full scheme, things will leak to the system, which is already a mistake we made with virtual environments, and none of the missing keys (
platinclude) should be installed to anyway.
IMO it is unwise to introduce new API/design that is bad by design.
You have two options:
Build a full scheme yourself
scheme = sysconfig.get_paths() | sysconfig.get_local_packages_paths()
You will have to write new code for PEP 582 anyway, so it’s not like this will be the thing preventing you from using old versions of installers (eg. pip), and I think it’s a reasonable enough ask.
Handle missing keys in installers
This would personally be my preference, and something installers should be doing anyway, as PEP 427 does not specify a canonical list of
The only breakage this may cause is not installing the
headersdata, which I think beats installing it on the system, a completely unrelated location. Realistically, this should basically only affect package building, which is recommended to be done in isolation anyway.
But if you think it is too much of a risk, go with 1), but acknowledging its issues. Once the
headersissue has been dealt with, you can then go back to just using the “partial” scheme as a full scheme.
platstdlibshould definitely not be installed to, I think it’s clear enough why.
platincludeare trickier, I would strongly discourage people from using them, as they are system directories, hence not isolated in virtual environments (!!), but installers do use them to calculate the path for the
headerskey, which is needed to keep backwards compatibility with the distutils install paths. I would also strongly discourage people from using that key, and recommend installers to raise a warning. Most projects have already moved away from using it, in favor of installing the headers as module data. Several, but not many, still remain, and IMO we should encourage them to move away from using it. ↩︎