PEP 632: Deprecate distutils module #1581
Conversation
|
Would be kinda cool to get Greg Ward (http://www.gerg.ca/) as a co-author. |
There was a problem hiding this comment.
This is a major change to the way c-extension modules are built, and will break most build scripts for c-extensions. Until now, python has been responsible for maintaining distutils, and the language of the PEP seems to be saying "nope, not our problem anymore". This is a major change. I think there should at least be one python release where distutils is deprecated but not removed. This would allow the wider ecosystem to accommodate the change. In addition to the projects visible on PyPI or conda, there are many non-public projects that this will impact. There needs to be very clear communication of migration paths (which could be as simple as the following), with a guarantee from setuptools that they will support current distutils usage. Another option may be to fork distutils out as a independent package, with the same level of support it has gotten from python in the last few years (very little).
try:
from setuptools import distutils
except:
import distutils
| latest documentation for migration advice. | ||
|
|
||
| Some projects use alternate sets of shims over distutils, notably, | ||
| numpy.distutils. [4]_ Where known, these projects have been informed. |
There was a problem hiding this comment.
Could you reference the informative message and the resulting discussion that took place with numpy and scipy?
There was a problem hiding this comment.
Do you mean pypa/setuptools#2372 ? "Have been informed" was only true immediately as I wrote it, because I interrupted typing at this point to make sure it had been mentioned ;)
There was a problem hiding this comment.
Thanks, I have now subscribed to that discussion.
| build the native extension modules in the standard library (except on | ||
| Windows). Because this is a CPython build-time dependency, it is | ||
| possible to continue to use distutils for this specific case without | ||
| it being part of the standard library. |
There was a problem hiding this comment.
It would be more convincing if CPython were to also commit to using setuptools exclusively in its build process.
There was a problem hiding this comment.
I addressed this on Discourse. CPython can use whatever internal tools it likes to build itself.
| Compatibility shims already exist in setuptools and pip to | ||
| transparently migrate old code, however, these are controlled by | ||
| external projects and are in no way bound by this PEP. Consult their | ||
| latest documentation for migration advice. |
There was a problem hiding this comment.
I think calling the PyPA-managed pip and setuptools projects "external" is not very accurate. Building such documentation should be a condition for accepting this PEP.
There was a problem hiding this comment.
This is a CPython PEP, and the relevant people have already indicated that they don't want to be bound to particular actions by a CPython PEP.
|
Let's not get too bogged down in details here on this PR. Once the PEP is merged and published, discussion about its content can take place elsewhere. @zooba You don't have a Discussions-To header, but the content of this PEP suggests that it's possibly a distutils-sig topic. Where was the conversation that led to this being created, and should further discussion about its content go to the same place? |
|
There's a Discourse thread at https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 |
|
... and the discussion thread promptly went to line 51 of my review here :) |
Technically distutils-sig would make sense, but that list is basically "pypa-sig" now, and this is not a PyPA topic. So python-dev is the |
|
I'm merging to make sure the PEP number is claimed and there is a rendered version on the website. It doesn't mean we're not going to make updates later. Initial discussions to https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 please |
No description provided.