On Tue, Sep 8, 2020 at 2:27 AM Steve Dower <steve.do...@python.org> wrote:
> On 07Sep2020 1602, Stefan Krah wrote: > > I'm under the impression that distutils has effectively been frozen for > > the last decade, except for the substantial improvements you made for the > > MSVC part. > > > > For Unix, no one has addressed e.g. C++ support. The underlying reason > > has always been that we cannot change anything lest it breaks someone's > > package. > > > > > > So I have some trouble understanding why we have exercised that kind > > of restraint (I might have committed a very small C++ patch otherwise) > > if we can now break everything at once. > > Others have contributed a range of little fixes over time. Maybe they > blur into the background noise of regular maintenance, but it does add up. > > The main reason we end up needing to fix things is because platforms > change things. Since we don't control _when_ platforms will change > things, we either do a single controlled break at a planned Python > version, or we allow it to break for different users at different times > that are not detectable from version number alone. It won't take long > for an autoconf-style approach to be necessary for figuring out how to > use distutils (though hopefully anyone who sees that as the solution > will also find https://packaging.python.org/ and find better solutions ;) > ) > > >> Unless you're offering to take over distutils maintenance? In which > case, > >> I'll happily withdraw the PEP :) > > > > No, thanks. :) > > Okay, maybe it is a little bit more than background noise ;) > And I think this is the key point. This open source project of ours has some truths about it, including: 1. Someone is using every piece of code somewhere in the world 2. The maintenance of any of it is not free What this PEP is arguing is that the cost/benefit ratio of "people directly using distutils" and "us keeping it afloat" does not work out in our favour enough to warrant us being the primary maintainers. Now I would also say this doesn't mean the setuptools maintainers should be expected to maintain it either; they want the code so they are forking it and are planning to keep it working for their needs. But if anyone else also wants to fork it and keep it running under a different backwards-compatibility policy than setuptools then obviously anyone can.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WADTZB5BNCK4I2JVC3UCKWL2PKWJGFXW/ Code of Conduct: http://python.org/psf/codeofconduct/
