
On 7/3/20 5:18 PM, Jason R. Coombs wrote:
I’m pleased to announce the release of Setuptools 48, which adopts the distutils codebase from CPython per pypa/setuptools#417<https://github.com/pypa/setuptools/issues/417> and pypa/packaging-problems#127<https://github.com/pypa/packaging-problems/issues/127>.
Given the amount of change this effort involved, it’s likely unstable and thus the major version bump. Please report issues at the Setuptools issue tracker. I’ll be around today (IRC, Gitter, Slack) to either disable the functionality or add an escape hatch if needed.
Thanks for doing that! At the Python language summit in 2018, I proposed to deprecate and maybe remove distutils from CPython. When looking at setuptools 49.3, I see that setuptools/_distutils still relies on distutils as distributed in CPython. Is this really wanted? I see distutils / setuptools mostly as a build time tool, which doesn't have to be installed at runtime, that's why you have a separate binary package in Debian/Ubuntu, called python3-setuptools. Examples for unexpected / creative usages, which are unrelated to building a package are: - distutils.version Used “everywhere”, moved back to the python package in Debian/Ubuntu. This maybe should be replaced by using distlib.version. - distutils.spawn: find_executable Replace with shutil.which, this can definitely go, because there's a replacement in the Python3 standard library, and starting with 48.x, setuptools only targets Python3. - distutils.util: strtobool Rewrite, no equivalent in the stdlib? - distutils.sysconfig: Mostly replaced by sysconfig Maybe I'm missing something, but as I currently see setuptools it has to follow CPython's ongoing changes in distutils, without an option to deprecate distutils any time soon, and it still provides things which from my point of view, it shouldn't provide. Matthias