PEP 632 - Deprecate distutils module

[pganssle (Paul Ganssle)]

@steve.dower

Their choice of build backend.

distutils has a bunch of stuff in it that is not related to your build backend.

@steve.dower

Out of scope for this PEP, as I think you’ll find that the range of existing build backends prefer to set their own schedules.

I realize that all of this is out of the specified scope of the PEP, but that I’m a strong -1 on this PEP unless the scope is expanded to include a plan for what to do.

Alternatively, I recommend modifying the PEP to no longer mention setuptools, since it’s irrelevant. The extent of the PEP can thus be, “We will deprecate distutils in Python 3.10 and remove it in Python 3.12. All current users must find an alternative.” Personally, I don’t think that’s very satisfying.

@steve.dower

Thanks for linking to the documentation for these modules… oh wait They’re not documented (except in a legacy page that says it’s all moving into setuptools). No matter why people are using them, they are not guaranteed public API, and despite that, we’re still offering two deprecated releases before they go away.

I don’t think it’s fair to say, “They’re not documented except for a legacy page saying they’re moving to setuptools” when my point is they are not moving to setuptools. “Setuptools provides the distutils module” is an intermediate step to a better future and I’d consider it a worse and more confusing outcome than the current situation if it happened indefinitely, TBH.

@steve.dower

Or we can normally deprecate them and aggressively find alternatives. I can’t dictate what setuptools should or shouldn’t include, so this sounds like a discussion to take over there.

I’ll point out again that distutils has been not-very-aggressively deprecated for over five years, and likely closer to ten (but that’s before my time).

I think by “aggressively deprecate” I meant that we would make it very clear that you should never declare a dependency on setuptools to get access to these functions — they’ll be removed there before they get removed from CPython.

@steve.dower

It’s open source, sure, anyone can do that. If anyone from the core team was willing to maintain distutils in its place, or anyone from the community wanted to join the core team and take ownership of distutils in its place, then we wouldn’t need to remove it. But since nobody wants to do that, I think you’ll be lucky to find someone willing to distribute it separately.

Oh, apart from setuptools

I’m talking about how, structurally, distutils gets maintained. In all the currently-proposed scenarios, we’re looking at distutils coming in via a 3rd party PyPI package. I believe the plan (though it’s not laid out here), is to then deprecate distutils both in CPython and in the 3rd party package, with the goal that in X years, nothing will support import distutils.

And no, random people can’t add a distutils package to PyPI because it’s “Open Source” — or at least they shouldn’t be able to, since standard library module names are reserved to prevent squatting.

In any case, I’m a strong -1 on this PEP as it stands. I think the concerns that led people to say that we should write a PEP for this are completely un-addressed, notably this, which echoes other things I’ve seen:

@encukou

Currently, to me it seems that the plans for distutils/setuptools are scattered across issues in several projects, so I’m not clear on what is actually happening. Would it be worth it for someone who’s following all this to write a PEP?

PEP or not, what we need is an overall migration plan so that we can explain to people why what we’re doing is not some horribly destructive thing for the ecosystem and to give them the ability to plan for future changes. “We’ll be removing distutils using the normal deprecation process, setuptools might support some parts of it I guess, but that’s up to them” is not that. It’s a huge migration likely to impact large swathes of the ecosystem, I think it deserves a design review.