Thanks everyone for your input so far.
Rest assured, I am very aware of air-gapped and limited network systems,
as well as corporate policies and processes. Having distutils in the
standard library does not help with any of these.
Do not forget that pip (and presently, though not permanently,
setuptools) are bundled with a recommended CPython distribution through
ensurepip. I call out "recommended" because distributors (including
those who are transferring CPython into an air-gapped system) can choose
to do whatever they like - including leaving out distutils already!
As for defining standards for installation, the sysconfig module
specifies the paths to install things (though even those can be taken
with a grain of salt, as it's really the import system and site module
that determine where things should be installed), but we already defer
to third parties to do the actual installation (including, yes, those
who use distutils to help define their install script). All other
packaging and distribution specifications are listed at
https://packaging.python.org/specifications/
Also, distutils has never been a "standard" for how to define a package
(i.e. write a setup.py), just as argparse is not a "standard" for how to
define a CLI. It's always been possible to do it in other ways, and the
current standard definition for this is now PEP 517. Since distutils is
not compatible with PEP 517, it is explicitly *breaking* the standard.
I also wanted to call out this excellent point from Emily:
If you can update to a breaking Python version, but aren't allowed one single
point version of an external module, you have a process problem.
This is absolutely the case. CPython, and the core team, cannot take
responsibility for bad policies, and (arguably) should not help users
work around those policies. It is better to provide useful advice to
organisations implementing these policies to help them do things
properly (this is a large part of what I get paid to do these days),
because otherwise they very quickly just dictate that Python cannot be
used at all.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/V2JKVPEDQPJJHF5W4MJRER5FBH3I4WLU/
Code of Conduct: http://python.org/psf/codeofconduct/
