# PEP 632 - Deprecate distutils module **URL:** \ **Category:** PEPs\ **Created:** [September 4, 2020, 12:20am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 "2020-09-04T00:20:47Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 4, 2020, 10:07pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/21 "2020-09-04T22:07:13Z")
> [@steve.dower](#): > > This seems like a good place to put (more) of those mappings: [https://setuptools.readthedocs.io/en/latest/distutils-legacy.html](https://setuptools.readthedocs.io/en/latest/distutils-legacy.html) It does, and adding that link to the PEP would seem like an easy way to alleviate at least some of the “where’s the migration advice?” questions. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 4, 2020, 10:37pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/22 "2020-09-04T22:37:55Z")
I’ve also just been reminded of this issue, filed by Jason, asking for as quick a deprecation as we can: [https://bugs.python.org/issue41282](https://bugs.python.org/issue41282) ---
**Author:** ![ronaldoussoren](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronaldoussoren/32/61_2.png) [@ronaldoussoren](https://discuss.python.org/u/ronaldoussoren)\ **Post date:** [September 5, 2020, 9:15am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/23 "2020-09-05T09:15:28Z")
I’m in favour of this PEP, as you write setuptools has replaced distutils for a significant majority of users (in particular anyone using pip, or even it predecessors). Furthermore development of distutils has stalled, even for bug fixes. Removing distutils is more honest to our users. I don’t agree with the proposed end state. I’d prefer to remove distutils entirely, not keep it as a private library. This will require more work on the \*nix build to replace the logic in setup.py (mostly to the configure script). The Windows port proves this is possible in principle. ---
**Author:** ![vsajip1](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip1/32/44_2.png) [@vsajip1](https://discuss.python.org/u/vsajip1)\ **Post date:** [September 5, 2020, 10:47am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/24 "2020-09-05T10:47:42Z")
I have some reservations/questions/comments about this proposal: 1. Does this mean everyone is forced to either use `setuptools` or else vendor `distutils`? I maintain `distlib`, which grew out of the aborted packaging effort in Python 3.3 and when `distribute` and `setuptools` were still separate, and `distribute` was the officially blessed installer tool. At the time of setting up `distlib`, it was meant to provide an alternative, PEP-based path (as opposed to the _de facto_ implementation-based `setuptools`/`distribute`, which had no PEPs behind them) to support features relating to package search and installation. Using `setuptools` in `distlib` wouldn’t make sense, if it’s meant to be an alternative. While you may want to deprecate `distutils` for its build-related functionality, `distlib` still uses code such as `distutils.core.Distribution` and `distutils.config.PyPIRCCommand` to base its functionality on. If you deprecate `distutils`, that’s one thing - but if you removed it entirely, `distlib` would stop working and there’d be extra work needed to avoid this. 2. “Historically, setuptools has extended distutils using subclassing and monkeypatching, but has now taken a copy of the underlying code. As a result, the second last major dependency on distutils is gone and there is no need to keep it in the standard library.” That suggests that `distutils` was only really around to support `setuptools`, and now that `setuptools` subsumes it, nobody else needs it. As per point 1 above, that isn’t the case. If you remove it because `setuptools` doesn’t need it any more, and “most people use setuptools”, that sounds like _the tyranny of the majority_ to me. Are you saying that all third-party tools that may have used `distutils` for needs beyond just actually installing packages (that “grab-bag of functionality”) don’t matter, and any extra work they need to do just has to be sucked up? This seems to contravene Python’s general stance on backward compatibility. 3. At the time `distlib` was set up, the prevailing idea seemed to be “Let’s define how things should work using PEPs. Then there could be multiple implementations which follow the PEPs, and people will choose what works for them, and there can be innovation while preserving interoperability”. Did I misunderstand that, or are we walking that back now? The message now seems to be more like “Let’s just use pip, wheel and setuptools for everything, it’s more convenient that way” - at least for the package installation side of things. As a maintainer who at least tried to create new things in this space, I find this message more than a little disheartening. ---
**Author:** ![FRidh](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fridh/32/10749_2.png) [@FRidh](https://discuss.python.org/u/FRidh)\ **Post date:** [September 5, 2020, 11:36am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/25 "2020-09-05T11:36:52Z")
> [@steve.dower](#): > > 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. This is a fun bootstrapping problem. To build CPython `setuptools` is needed, and to build `setuptools` Python is needed. Will the CPython source vendor a copy of `setuptools` for this purpose? `setuptools` vendors its dependencies, but at one point also chose not to do that. In case `setuptools` won’t be vendored, can it be guaranteed `setuptools` won’t choose to unvendor its dependencies again? Talking about bootstrapping, Python is nowadays used quite early in bootstrapping the build of Linux distributions from source since it’s a build-time dependency of `glibc`. In Nixpkgs we currently build a minimal Python 3 to deal with this, which does not include a lot of the extension modules. If modules that are included don’t use `distutils` it is less of a problem. > [@steve.dower](#): > > More likely we’ll migrate CPython’s extension modules to build through make. I know some people were keen to do this anyway. If that happens, the core build won’t use distutils either. Without further investigation, unless CPython would embed a copy of `setuptools`, I consider this a prerequisite for removing `distutils` from private use in CPython. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 5, 2020, 12:24pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/26 "2020-09-05T12:24:50Z")
> [@vsajip1](#): > > At the time `distlib` was set up, the prevailing idea seemed to be “Let’s define how things should work using PEPs. Then there could be multiple implementations which follow the PEPs, and people will choose what works for them, and there can be innovation while preserving interoperability”. Did I misunderstand that, or are we walking that back now? The message now seems to be more like “Let’s just use pip, wheel and setuptools for everything, it’s more convenient that way” - at least for the package installation side of things. As a maintainer who at least tried to create new things in this space, I find this message more than a little disheartening. My (personal, and interop standards PEP-delegate) view is that we are very much still taking the approach that defining standards and building tools based on those standards is crucial. And very definitely, we should be pushing for innovation rather than a “one tool to rule them all” approach. One frustration, though, is that _users_ don’t really want that - it’s next-to impossible, for example, to get people to accept that using an additional tool is a viable alternative to asking for functionality to be added to pip 🙁. So for all that we’re trying to create an open platform for tools to innovate, people are voting with their feet. To bring the comment back to the point, the problem is that distutils doesn’t implement any of those standards. And the lack of maintenance means it probably never will. So I don’t think standards-based interop is an argument against removing distutils. (It may be an argument against assuming that people can use setuptools instead, though). To address your examples: - Standardising an equivalent of the `distutils.core.Distribution` would allow other tools to implement it. Or maybe the stdlib interface `importlib.metadata.Distribution` is the new standard (the stdlib doesn’t have to define standards - it _is_ the standard, by definition 🙂). - On the other hand, the `.pypirc` configuration file has never been standardised, so code using distlib to process it are by default using an implementation defined approach. Unlike `importlib.metadata`, the distutils interface was never documented, so we can’t say “defined by the stdlib means standard” for this one… In my view, the transition work needed here would have been to pick out those parts of distutils that could usefully be standardised and do so. Then, new tools could have been written to allow code to migrate away from distutils. Sadly, in spite of years of warnings that distutils isn’t maintained, no-one has done much of that. So in that sense, I support deprecating distutils, because it pushes people to make that effort - split out code into independent libraries, push for standardisation, etc. Where I disagree with the PEP is in the presumption that the core devs can just “pull the plug” without looking at the impact on the ecosystem. Yes, removing distutils from the stdlib is hard. Yes, putting it on PyPI in some form helps. But I think we owe it to the community to do better than that. Heck, [PEP 594](https://www.python.org/dev/peps/pep-0594/) had a _really_ hard time, to the point where it’s still not agreed. And that was talking about removing libraries which are _far_ less critical to the Python community… ---
**Author:** ![vsajip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip/32/44_2.png) [@vsajip](https://discuss.python.org/u/vsajip)\ **Post date:** [September 5, 2020, 12:42pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/27 "2020-09-05T12:42:27Z")
> [@pf\_moore](#): > > So for all that we’re trying to create an open platform for tools to innovate, people are voting with their feet. Well, to some extent they’re being pushed in certain directions. This very PEP is pushing people to use `setuptools`. > [@pf\_moore](#): > > So I don’t think standards-based interop is an argument against removing distutils. I’m not making _that_ argument against removing `distutils` - it’s more about breaking third-party code such as `distlib` that uses `distutils` to build on. I have no problem with _deprecating_ `distutils`, by which I mean “don’t use `distutils` for new code unless you know what you’re doing and are prepared to work around bugs which surface, because `distutils` won’t get any maintenance love”. That’s altogether different to _removing_ code and causing breakage, for no good reason that I can see. > [@pf\_moore](#): > > I support deprecating distutils, because it pushes people to make that effort - split out code into independent libraries, push for standardisation, etc. > > Where I disagree with the PEP is in the presumption that the core devs can just “pull the plug” without looking at the impact on the ecosystem. Yes, exactly. Deprecate, by all means, but don’t break existing third-party code for no good reason by _removing_ `distutils`. Since it isn’t being maintained, it’s not really a burden, other than the disk space it takes up (which is not a big deal, really). ---
**Author:** ![pganssle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pganssle/32/245_2.png) [@pganssle](https://discuss.python.org/u/pganssle)\ **Post date:** [September 5, 2020, 2:49pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/28 "2020-09-05T14:49:01Z")
> [@vsajip](#): > > Yes, exactly. Deprecate, by all means, but don’t break existing third-party code for no good reason by _removing_ `distutils` . Since it isn’t being maintained, it’s not really a burden, other than the disk space it takes up (which is not a big deal, really). As I mentioned on `python-dev`, if you want to say that the only cost to “leaving `distutils` in the standard library” is disk space, you need to disable the tests for it so that it can’t break the build or the buildbots, you need to make it so people can’t file issues for `distutils` in CPython (triage takes time!), and make it so people can’t submit PRs modifying it. The difference between that “zero cost” scenario and the “deprecate and remove” scenario is that in the “deprecate and remove scenario”, there’s a clear timeline for when `distutils` breaks. In the “stop touching it or testing it at at all” scenario, different parts of it will break randomly at different times as bitrot sets in (can’t build Windows C extensions anymore because the compiler moved, can’t upload to PyPI anymore because the metadata is not standards-compliant, etc). Eventually Python will change such that `import distutils` breaks because something `distutils` is importing has moved or something, and then `distutils` will just be broken. This will happen at a random, unpredictable time. It is much better for us to break `distutils` up and distribute it among the projects that want to maintain the relevant functionality. Already the build backend functionality of `distutils` is basically maintained in `setuptools` via monkey patches (many people don’t realize that their code using `import distutils` would break without running `import setuptools`, because `pip` injects it silently and they always use `pip`). `distutils.version` is moved to `packaging`. I"m -1 on this PEP, but only because it doesn’t address the key issue: a clear path forward that would _not_ be horribly disruptive to the ecosystem. But I’m definitely +1 on a migration out of the standard library. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 5, 2020, 2:57pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/29 "2020-09-05T14:57:15Z")
> [@FRidh](#): > > This is a fun bootstrapping problem. To build CPython `setuptools` is needed, and to build `setuptools` Python is needed. Will the CPython source vendor a copy of `setuptools` for this purpose? No, CPython doesn’t currently depend on setuptools to build itself, and it seems unlikely that will even happen. As with the rest of its build, it’ll use custom build scripts, and at worst, will take a private copy of distutils for this purpose. > [@FRidh](#): > > Without further investigation, unless CPython would embed a copy of `setuptools` , I consider this a prerequisite for removing `distutils` from private use in CPython. Agreed. Luckily, this PEP is not proposing to remove it from _private_ use (though a number of other people have proposed migrating CPython’s extension modules to another build system, such as @ronaldoussoren above). What CPython uses for its own build is completely indepenent from this PEP, and it’s only mentioned because people will rightly insist on pointing it out. > [@vsajip1](#): > > Does this mean everyone is forced to either use `setuptools` or else vendor `distutils` ? You can also use another build backend, such as Flit, Poetry, pymsbuild, enscons, or anything else that is invented. The standards have settled on PEP 517, which is a standard way to declare which build tool you require - distutils is not (and will never be) updated for this standard. > [@vsajip1](#): > > That suggests that `distutils` was only really around to support `setuptools` , and now that `setuptools` subsumes it, nobody else needs it. My apologies for missing distlib. I’m happy to give you a mention in the PEP along with numpy.distutils if that will satisfy you? Also, I suggest looking up the distutils docs, which for the last decade have said that they’re only around for the sake of setuptools. This happened before my time, so it’s the best I have to go on 🤷‍♂️ > [@vsajip1](#): > > The message now seems to be more like “Let’s just use pip, wheel and setuptools for everything, it’s more convenient that way” - at least for the package installation side of things. As a maintainer who at least tried to create new things in this space, I find this message more than a little disheartening. The message is now “use PEP 517 compatible backends”. Sorry you didn’t hear about it, we talked about it quite a lot on distutils-sig and here on Discourse. > [@vsajip](#): > > This very PEP is pushing people to use `setuptools` . setuptools is the most compatible migration target for current users of distutils for packaging purposes. They also publish documentation (currently not very complete) for people who need to migrate to other libraries such as shutil. And as I said above, distutils has been pushing users towards setuptools for years, so this is just the continuation of that. ---
**Author:** ![vsajip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip/32/44_2.png) [@vsajip](https://discuss.python.org/u/vsajip)\ **Post date:** [September 5, 2020, 5:02pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/30 "2020-09-05T17:02:52Z")
> [@steve.dower](#): > > You can also use another build backend, such as Flit, Poetry, pymsbuild, enscons, or anything else that is invented. > [@steve.dower](#): > > The message is now “use PEP 517 compatible backends”. Sorry you didn’t hear about it, we talked about it quite a lot on distutils-sig and here on Discourse. You seem to be treating `distutils` as _only_ a build system, but it’s not. The usage of `distutils` by `distlib` doesn’t relate to building extensions, and so your reference to alternative build backends doesn’t apply to it. Is it that you haven’t considered the _other_ uses of `distutils`? It appears not, from your suggested migration path: > Code that imports distutils will no longer work from Python 3.12. > > The suggested migration path is to use the equivalent (though not > identical) imports from setuptools (see [5]), or to migrate to an > alternative build backend (see PEP 517 [4]). If you haven’t considered these other usages of `distutils`, I respectfully suggest that this PEP is incomplete, and perhaps premature because not enough thought has gone into downsides of deprecation/removal. > [@steve.dower](#): > > So I think two things are being conflated here. The first that distutils is (the core of) a build backend, and the second is that distutils is a grab bag of random functionality. They deserve to be treated separately. But by saying you want to deprecate and remove all of `distutils`, aren’t you the one doing the conflating, by treating the two things as a unit? > [@steve.dower](#): > > I’m not personally interested in drawing the line, so if someone would like to define which parts of distutils are part of the build backend, which parts are the grab bag, and which parts don’t matter, I’m happy to include that information in the PEP (and make whoever wrote it a co-author). > [@steve.dower](#): > > My apologies for missing distlib. I’m happy to give you a mention in the PEP along with numpy.distutils if that will satisfy you? Why is it just a matter of mentioning it in the PEP? Is it OK to take the view that “as long as the breakage to come is documented somewhere, that’s all we need to do”? That seems to be what you’re saying, but tell me if I’m misinterpreting. I care about unnecessary breakage of existing code, not in `distlib` getting a mention in the PEP (though it could be mentioned, by virtue of being a library which uses `distutils` that’s vendored by `pip` and `virtualenv`, and not just to satisfy me 🙂). When you say > I’m not personally interested in drawing the line That’s fair enough as far as stating what you care and don’t care about, but that doesn’t mean that non-buildsystem usages of `distutils` should be ridden-over roughshod just because you, and no doubt some other people, don’t care. I appreciate that I was a bit simplistic in saying that disk space was the only cost of keeping `distutils` around - thanks @pganssle for the reminder that there’s more to it. 😳 😬 > [@pganssle](#): > > I"m -1 on this PEP, but only because it doesn’t address the key issue: a clear path forward that would _not_ be horribly disruptive to the ecosystem. I agree - I too think the PEP needs more fleshing out about how disruption would be minimized, about separating the non-build from the build-parts in the discussion, etc. Surely the onus is on those who want to _change_ the status quo to make a detailed proposal showing how disruption could be minimized for all stakeholders? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 5, 2020, 5:30pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/31 "2020-09-05T17:30:56Z")
> [@vsajip](#): > > You seem to be treating `distutils` as _only_ a build system, but it’s not. Guess I was confused by the docs: > The [`distutils`](https://docs.python.org/3/library/distutils.html#module-distutils) package provides support for building and installing additional modules into a Python installation. If it truly is a package of useful other functionality, it’s a shame it’s not documented. Hopefully now that there is some enthusiasm for this functionality, someone will step up to document, support and maintain it? ---
**Author:** ![rgommers](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rgommers/32/837_2.png) [@rgommers](https://discuss.python.org/u/rgommers)\ **Post date:** [September 5, 2020, 10:21pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/32 "2020-09-05T22:21:00Z")
Hi, thanks for working on this PEP Steve. I’m supportive of the goal of this PEP - it has to happen at some point. The text seems to gloss over some not-so-minor details though, so I hope the PEP can be updated with a more accurate description of the needed effort and backwards compatibility impact. > [@steve.dower](#): > > As a result, the second last major dependency on distutils is gone and > there is no need to keep it in the standard library. You do give numpy.distutils a mention, but I’d like to point out that it is a major dependency on distutils: - It depends only on distutils, not on setuptools, - It is older than setuptools (2001 vs. 2004), - It has more build-related lines of code than setuptools (~20,000 LoC vs. ~15,000 LoC), - It has different and sometimes incompatible monkeypatches from setuptools, - It has significantly more build-related functionality than setuptools (summarized in [how to handle numpy.distutils and setuptools interaction · Issue #2372 · pypa/setuptools · GitHub](https://github.com/pypa/setuptools/issues/2372)). And it is in turn depended on by SciPy, scikit-learn, scikit-image, statsmodels, and many other projects. > [@steve.dower](#): > > As > these packages are already subject to setuptools overriding distutils, > we expect minimal disruption as a result of distutils being removed. The discussion so far has probably already shown that this isn’t the case. From my perspective as a NumPy and SciPy maintainer, the amount of work this will cause is huge - second only to the Python 2-\>3 migration. It’s an estimated 6-9 months of work for setuptools to complete incorporating distutils and exposing its functionality as setuptools APIs. Then it will take at least that same amount of time for numpy.distutils functionality to be updated for that and split off as a separate package or merged into setuptools as well. And after that the downstream users of numpy.distutils need updating. So that’s probably ~2 years of work before this whole exercise is over. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 5, 2020, 11:03pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/33 "2020-09-05T23:03:57Z")
> [@rgommers](#): > > You do give numpy.distutils a mention, but I’d like to point out that it is a major dependency on distutils: The point is not to make it sound like people should try and switch to it. Unlike setuptools, which has always explicit been trying to be a substitute for distutils, numpy has not and is not. Already I’ve been asked to “list more projects” and also “oh, but not mine please”, so it’s really not clear what people expect to see here. What I do know is that basically any specifics in the PEP itself will be outdated almost immediately, and certainly by the time distutils is actually removed from the stdlib. > [@rgommers](#): > > The discussion so far has probably already shown that this isn’t the case. Nobody in the discussion has suggested that setup.py files will break, or that the PEP is responsible for those. Only that an unspecified set of helper functions do not have immediately obvious alternatives. > [@rgommers](#): > > So that’s probably ~2 years of work before this whole exercise is over Luckily the deprecation period will last approximately three years, so thank you for confirming that it’s long enough ☺ (don’t worry, I won’t quote you in the PEP on that, since I know that’s not what you were trying to suggest). Ultimately, I volunteered to write a PEP that essentially formalises the status quo for most of the last decade, which “everyone” knew was necessary, but nobody had done officially. I know a lot of the trouble you’ve already dealt with in numpy trying to play nice with distutils, and this is apparently the only way for us to officially say “it’s okay, you don’t have to use us anymore” (in a way that’s also convenient for you to point your own users at). The same applies for setuptools. Your two projects know better than most how hard it is to work against the “standard”, so hopefully this clarifies that you’re welcome to do whatever you need to enable your users and ignore “what upstream thinks” here. ---
**Author:** ![rgommers](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rgommers/32/837_2.png) [@rgommers](https://discuss.python.org/u/rgommers)\ **Post date:** [September 6, 2020, 12:01am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/34 "2020-09-06T00:01:18Z")
> [@steve.dower](#): > > Nobody in the discussion has suggested that setup.py files will break, or that the PEP is responsible for those. Well, in that case: `setup.py` files will break, in multiple ways and with obscure errors. > [@steve.dower](#): > > so it’s really not clear what people expect to see here. I don’t care much about the specifics, I’m happy to work out the plan together with setuptools and other projects as we go. I just want the PEP to be somewhat reflective of reality, because this will be the largest backwards compat break in a long time. ---
**Author:** ![vsajip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip/32/44_2.png) [@vsajip](https://discuss.python.org/u/vsajip)\ **Post date:** [September 6, 2020, 6:09am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/35 "2020-09-06T06:09:33Z")
> [@steve.dower](#): > > Nobody in the discussion has suggested that setup.py files will break Well, any project that doesn’t use `setuptools` but does use `distutils` will have code in its `setup.py` like ``` from distutils.core import setup # other stuff setup(...) ``` Does it need explicit spelling out that if the `import` fails because `distutils` has been removed, any such `setup.py` file will break? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 6, 2020, 6:48am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/36 "2020-09-06T06:48:29Z")
> [@vsajip](#): > > Does it need explicit spelling out that if the `import` fails because `distutils` has been removed, any such `setup.py` file will break? When invoked via pip, it will be subject to their injection of setuptools (until the project specifies a build backend, which can’t be distutils anyway) and so will work for as long as setuptools provides a shim. But the PEP cannot dictate how setuptools behaves. It’s already spelled out that direct imports of distutils will fail. That’s normal for API changes and it’s what the deprecation period is for. > [@rgommers](#): > > Well, in that case: `setup.py` files will break, in multiple ways and with obscure errors. That’s what happens today anyway, and was the motivation for PEP 517. This change will make them break in a single consistent way (ModuleNotFoundError) from a known Python version (3.12) in a known and well advertised schedule (approx 3 years). That seems like an improvement. ---
**Author:** ![vsajip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip/32/44_2.png) [@vsajip](https://discuss.python.org/u/vsajip)\ **Post date:** [September 6, 2020, 7:10am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/37 "2020-09-06T07:10:36Z")
> [@steve.dower](#): > > When invoked via pip But that’s not the only way of installing, even if it is the most common. What about `python setup.py install`? > [@steve.dower](#): > > and so will work for as long as setuptools provides a shim. But the PEP cannot dictate how setuptools behaves. Things look OK now, but in the past it’s been a wild ride 😉, and there’s no telling what will happen in the future. It seems reasonable that there should be some minimalist way of installing simple Python packages without _mandating_ the usage of a third party tool, however ubiquitous. > [@steve.dower](#): > > That’s what happens today anyway, and was the motivation for PEP 517. That’s build functionality again (I’m not arguing about the brokenness of `distutils` build functionality, or the fact that its original design was problematic - just trying to avoid unnecessary breakage due to throwing the baby out with the bathwater). > [@steve.dower](#): > > This change will make them break in a single consistent way (ModuleNotFoundError) Other approaches are possible to at least consider. For example, fail consistently only when certain problematic constructs within `distutils` are accessed, such as parts of `Lib/distutils/command` and `distutils/XXXcompiler.py`. Perhaps via a `NotImplementedError` with a message indicating workarounds. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 6, 2020, 7:37am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/38 "2020-09-06T07:37:04Z")
> [@vsajip](#): > > Other approaches are possible to at least consider. For example, … They’ve been considered but would require more maintenance work than we have available for distutils. As I said earlier, you’re welcome to take it on. Given a dedicated maintainer I’m happy to withdraw the PEP (until that maintainer disappears on us). ---
**Author:** ![vsajip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vsajip/32/44_2.png) [@vsajip](https://discuss.python.org/u/vsajip)\ **Post date:** [September 6, 2020, 8:07am UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/39 "2020-09-06T08:07:13Z")
> [@steve.dower](#): > > They’ve been considered By whom? Is there discussion somewhere which goes into detail? > [@steve.dower](#): > > As I said earlier, you’re welcome to take it on. Given a dedicated maintainer I’m happy to withdraw the PEP Is the suggestion that if someone doesn’t step up and take ownership of _all_ of `distutils`, it _has_ to _all_ be removed, potentially breaking lots of third-party code? No ifs, no buts? Bit of a Hobson’s choice. Did something happen recently to precipitate such a drastic move? I’m just trying to get clarity about the next steps here. The PEP has been drafted, and concerns have been raised about unnecessary breakage of third-party code if it’s implemented as is. Is it not primarily the responsibility of the PEP author, as the one proposing the change, to take ownership of addressing those concerns? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 6, 2020, 12:12pm UTC](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/40 "2020-09-06T12:12:27Z")
> [@vsajip](#): > > By whom? Is there discussion somewhere which goes into detail? At least by the PEP author, since I seem to have the responsibility for these things 🙂 But in reality, they’ve been discussed frequently over the last decade in various conversations, both online and in person. I wasn’t around for most of them, but the summary was captured in the _official distutils documentation_ in 2014 or earlier, which says please don’t use it and use setuptools instead. > [@vsajip](#): > > Is the suggestion that if someone doesn’t step up and take ownership of _all_ of `distutils` , it _has_ to _all_ be removed, potentially breaking lots of third-party code? No ifs, no buts? Bit of a Hobson’s choice Basically, yes. As long as the import succeeds, people will expect every part of it to work. Deprecations/removals always break third-party code that is using the deprecated functionality, and there are plenty of options for that code, ranging from not updating to Python 3.12 through to migrating to alternate functionality. > [@vsajip](#): > > I’m just trying to get clarity about the next steps here. Which next steps? If you’re using distutils for packaging, switch to setuptools (for closest compatibility) or another backend. If you’re using distutils for something else, at least tell me what so I can give you a specific answer. Otherwise my answer remains “follow setuptools’s guide for migrating to things that setuptools does not offer”. [Previous page](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134.md?page=1) [Next page](https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134.md?page=3)