This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author doko
Recipients brett.cannon, christian.heimes, doko, dstufft, eric.araujo, jaraco, lukasz.langa, ncoghlan, ned.deily, p-ganssle, pablogsal, paul.moore, steve.dower
Date 2020-07-14.09:39:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> A PEP may be a good idea, but I do think the change doesn't have a
> particularly large magnitude. Anyone using setuptools or pip has
> already been getting setuptools' monkey-patched version of distutils
> for ages now, and soon they will be getting setuptools' vendored
> version. The documentation already indicates that distutils is at
> least soft-deprecated in favor of setuptools and we've already been
> directing issues and PRs to setuptools instead of distutils.

I don't think it's a good idea to replace bad habits from distutils with bad habits in setuptools._distutils.  And this is exactly what you get with pointing directly to setuptools.

While splitting out distutils to a separate package in a Linux distro, I found some creative usages at runtime of a package (see my lightning talk at the language summit 2018, and [1]).  From my point of view, CPython should provide documentation how to forward-port these issues without using setuptools._distutils.

Currently setuptools only has one component (pkg_resources, [2]) which is used at runtime.  I dislike it if more than that is used at runtime of a package.

Date User Action Args
2020-07-14 09:39:02dokosetrecipients: + doko, brett.cannon, paul.moore, jaraco, ncoghlan, christian.heimes, ned.deily, eric.araujo, lukasz.langa, steve.dower, dstufft, p-ganssle, pablogsal
2020-07-14 09:39:02dokosetmessageid: <>
2020-07-14 09:39:02dokolinkissue41282 messages
2020-07-14 09:39:01dokocreate