Indeed – this is major step forward! On 3.7.2020 18.59, Paul Moore wrote:

Awesome! Congratulations on achieving this :-) Paul

On Fri, 3 Jul 2020 at 16:26, 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 and pypa/packaging-problems#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. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/74WZ7... -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/EWWVJ...

I don't think setuptools actually /does/ rely on the distutils from the standard library. One of the first things setuptools does is replace the distutils module in sys.modules with setuptools._distutils https://github.com/pypa/setuptools/blob/37d81f4ce8f08c4baf44b6ff0f3f1bd3f6b2.... Anywhere else in the codebase that you see any variation on import distutils, you /should/ get code exclusively from setuptools._distutils. I believe we're disconnecting from distutils and replacing it. I think we should be able to deprecate distutils in Python 3.10. I don't think there's ever been explicit agreement on this point, but my understanding is that we're planning on moving everything from the distutils namespace into setuptools (and we're in the very long and drawn-out process of a massive widdling-down of the functions setuptools / distutils provides, so you can rest assured we'll be deprecating the pointless stuff). Best, Paul On 7/13/20 9:57 AM, Matthias Klose wrote:

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#417https://github.com/pypa/setuptools/issues/417 and pypa/packaging-problems#127https://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 -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/NXR4Z...

On Jul 13, 2020, at 11:36, Matthias Klose wrote:

On 7/13/20 4:26 PM, Paul Ganssle wrote:

...

I don't think setuptools actually /does/ rely on the distutils from the standard library.

One of the first things setuptools does is replace the distutils module in sys.modules with setuptools._distutils https://github.com/pypa/setuptools/blob/37d81f4ce8f08c4baf44b6ff0f3f1bd3f6b2.... Anywhere else in the codebase that you see any variation on import distutils, you /should/ get code exclusively from setuptools._distutils.

I believe we're disconnecting from distutils and replacing it. I think we should be able to deprecate distutils in Python 3.10. I don't think there's ever been explicit agreement on this point, but my understanding is that we're planning on moving everything from the distutils namespace into setuptools (and we're in the very long and drawn-out process of a massive widdling-down of the functions setuptools / distutils provides, so you can rest assured we'll be deprecating the pointless stuff).

what I want to avoid is that imports like distutils.spawn.find_executable are just replaced by setuptools._distutils.spawn.find_executable. From my point of view it doesn't make sense to replace a bad usage with another bad usage.

Maybe it's worth to mention the distutils deprecation for 3.10 already in 3.9, so people will have more time to adopt.

Before we can think about deprecating, we need to have a plan that has been reviewed and approved. Removing Distutils is a major change on the cpython side. My comment on https://bugs.python.org/issue41282 "Deprecate and remove distutils" "So what is the plan to continue to support building cpython itself which depends on Distutils? Currently the build bootstraps itself without the aid of an existing Python interpreter instance. There would also be major impacts across the whole cpython development process. For example, there are many open Distutils issues in the bugs.python.org bug tracker. We need a plan on how those are to be handled (and that should take into account the expected transition from b.p.o to GitHub issues). People will continue to submit issues agains Distutils there so triage team members and core developers need to know how to handle such issues. What if an issue applies also or only to a previous release branch (i.e. where Distutils is still in the repo)? What about Distutils documentation in the Python docset? THose are just some off the top of my head. I don't think any of these issues are necessarily blockers but they need to be planned for and reviewed. I think a PEP is definitely in order for a change of this magnitude." -- Ned Deily nad@python.org -- []