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 <1594719542.34.0.71010976477.issue41282@roundup.psfhosted.org>
In-reply-to
Content
> 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.

[1] https://mail.python.org/archives/list/distutils-sig@python.org/thread/74WZ7D3ARF7B3N6MAV2JBV3DW6TRHFIV/
[2] https://github.com/pypa/setuptools/issues/863
History
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: <1594719542.34.0.71010976477.issue41282@roundup.psfhosted.org>
2020-07-14 09:39:02dokolinkissue41282 messages
2020-07-14 09:39:01dokocreate