[Petr] Use-case not covered: older distros that aren't updated.
[jaraco] Mentioned concern about Python version in egg-info. Defer until Mathias has more information.
https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/104
[mathias] Two issues mainly (Debian):
Fedora (and most likely Debian):
/usr/local/lib64/pythonX.Y
by default/usr/lib64/pythonX.Y
(used when building RPM/DEB packages)/usr/local/lib64/pythonX.Y/site-packages
in sys.path
first, but not with -s
PKG-INFO
-less installations
sudo pip install -U ...
fail anywayIssue: sudo pip install -U setuptools
loses patches
pip: Long plan to move to sysconfig from distutils.sysconfig.
[Miro] Proposal: platforms can patch sysconfig and distutils can rely on that to load install schemes. That means setuptools can only switch to its distutils for Python 3.10+ (assuming we do this in 3.10).
[Jason] Problem: Old Python versions. Setuptools would like to be able to change distutils.
[Jason] Define schemes in setuptools…distutils that "work good enough" for both Debian and Fedora.
[Mathias] Sysconfig is a mess; exposes too much. Need vision first.
[Pradyun] distutils would need a stopgap solution until 3.9 goes EOL.
[Jason] Short term, let's have a "hook" the distributors can put to the standard library… For long term, define better defaults.
[Miro] Defaults that satisfy everybody may not be possible.
Design (install schemes):
INSTALL_SCHEMES
defined for compatibility with Python < 3.10
INSTALL_SCHEMES
to sysconfig and imports them to distutils for backwards compatibilityINSTALL_SCHEMES
from sysconfig if found, fallbacks to its own definition if notProblem: INSTALL_SCHEMES
don't contain logic of picking the appropriate scheme.
Possible solution: See sysconfig._get_default_scheme()
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L179 - distros would patch (or patch-add) this.
Debian has --install-layout
for distutils, we can keep that in pypa/distutils and make it override sysconfig._get_default_scheme()
value.
Next steps:
Well, that didn't make anyone's day worse, I think. :)
dist install Python to /usr
as user build from source to /usr/local
How to avoid: both installations pull libraries from /usr/local/lib/python/site-packages
?
Proposal: We should disallow /usr
loading any packages from /usr/local
.
Issue - still need multiple package directories for each Python installation. Why? To avoid conflicting pip-installed packages with package manager-installed packages. Package managers can elect an install scheme for this need.
Goal: Uniform behavior (including bugfixes and improvements in pypa/distutils) on all Pythons supported by Setuptools (3.6+).
How to use new distutils with old CPythons?
SETUPTOOLS_USE_DISTUTILS=stdlib
. (discouraged)sysconfig
and fallback to default behavior (breaks when expecting custom behavior).Why not just use INSTALL_SCHEMES from sysconfig? That's a good plan to aim for.
Proposal: Solicit flag from sysconfig to signal that it was patched to be compatible with new scheme.
Currently, sysconfig.INSTALL_SCHEMES
does not exist. Could that serve as the flag?
When it exists on older Pythons (any), use it. If not, detect patch distutils (Debian, Fedora), warn that behavior may not be compatible with Distribution-patched distutils.
How important is this use-case?
Proposal: Remove 'unix-local' scheme.
It's just a footgun.
Let's explore the possibility.
How does site
use install schemes:
Is a PEP needed?
Next steps: