Can you describe why that is needed? This approach solves the issue Fedora is trying to mitigate in a different way, but solves it nonetheless.
The way this is supposed to fix it is that distributors, such as Fedora, would add a new install scheme, say
fedora, that will use
fedora-packages instead of
site-packages. Then, when building packages, Python modules would be installed there instead of the default scheme (which uses
Python installers such as
pip, will use the default scheme and so, it will never mess with the distro packages.
I remember @pf_moore said it would make sense for pip to gain a
--install-scheme argument, which would work for Fedora’s package install use-case.
I believe this to be better than Fedora’s approach because it does not hijack another perfectly valid Python installation (
The issue with allowing distributors to directly inject code into
sysconfig is that then they can change expected behaviors, which is not good, and brings us back to the current issue – distributors patching the Python installation in ways that cause expectations to be broken, and with wildly different approaches. If that’s the case, I’d rather just having them patching
sysconfig directly, without explicit upstream support.
What I wanted to achieve with the config was to allow distributors to do what they need in a way that is not intrusive and will not break any behaviors/expectations. This is a big problem right now, and I think defining a set of rules that work for everyone, and that everyone should play by, is the best way to resolve this.