That can be a solution, but the hard question is what do we allow them to change? My main worry is that is likely something that can’t be expressed in a static data file.
Fedora, for eg, patches sysconfig to only change the default scheme when RPM_BUILD_ROOT is defined, meaning it only happens inside when building an RPM package.
Anyway, I think the reason these patches break expected behavior is because IMO they are conceptually wrong, as nothing related to the /usr Python should be installed to /usr/local [1], breaking the core design of how prefixes are supposed to work. IMO this is a vendor bug – because the design is not compatible with such thing, they simply add /home after the prefix placeholder in the sysconfig scheme templates, which is objectively incorrect. I think pip has a very strong case to simply close these bugs as a vendor bug and tell people to report them to the vendor.
We can standardize a data file, but without fixing these conceptual divergences, I don’t think it’d change much, it’d only serve to let tooling more easily detect and understand vendor patching, so they can maybe undo it.
The solution I have been proposing for a while now is to add an officially CPython-supported way to perform patching that can achieve the high-level outcome that vendors want, in hope that it may deter them from patching Python in broken ways.
-
The FHS 3.0 says that the
/usr/localprefix “may be used for programs and data that are shareable amongst a group of hosts, but not found in/usr”. ↩︎