My sense of the current position is: - distutils exists for both Python and the broader ecosystem to build both extension modules and package distributions - we recognise that its able to do anything, but many folk find it hard to work with - or are already invested in other build tools - we're afraid of changing it in ways that cause incompatibilities with e.g. the numpy eco systems heavy customisations, and we're not sure we can recognise whether a given change is one of those - and we're recommending that everyone move away from directly using distutils to using setuptoools - but setuptools *is* distutils in many many ways, so this doesn't loosen our dependency and stability considerations around distutils
So basically the normal 'module goes to the stdlib to freeze' effect. I haven't read about Sylvain's proposed changes yet - ETHINGSTODO :(. I can happily agree with a position that making distutils directly usable is a non-goal... but insofar as making it more usable makes setuptools more usable, that would be a goal :/. -Rob On 29 August 2016 at 05:05, Brett Cannon <br...@python.org> wrote: > The discussion of Sylvain's proposed changes to distutils suggests that > there isn't a clear-cut agreement or position of this SIG -- and thus Python > -- on changes to distutils, its future, etc. Is there an official position > I'm not aware of? If not, could we get one so we know how to handle any more > proposed changes to distutils? > > For me personally (and to start this conversation if necessary), I view > distutils as the package in the stdlib that handles building extension > modules in the stdlib for Python. That view means that if something doesn't > service that explicit goal then it shouldn't go into distutils. Now that we > are moving down the road towards making the build step configurable I'm fine > with saying that distutils is not expected to work for people other than > Python itself and others can use setuptools, enscons, or other projects > while we continue to improve the situation to where the build system is just > something you specify in pyproject.toml to generate your wheel. IOW > distutils is only exposed publicly because Python doesn't hide anything, but > making it useful for the general case of direct usage by people is a > non-goal of the package. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig