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 ;)
I've looked at the log, most maintenance patches are from a variety of
active core devs (this includes, of course, the MSVC patches from you).
Will they submit patches to setuptools from now on?
If you look at the setuptools history, a variety of contributors have
submitted much the same (and often better) fixes there. I expect I
likely will as well, inasmuch as they are needed to help Windows users
be successful, though I also have my own backend that will likely be
where big features that interest me end up ;)
It's easier and more satisfying to submit the patches to setuptools, as
the release comes out much sooner (and can be installed on earlier
versions), and it will only get easier when _all_ the code can be fixed
there. Right now, one of the biggest pains there is having to do loads
of careful monkeypatching to fix one poor choice in the standard library.
Cheers,
Steve
_______________________________________________
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/7MESZKL5KFX6YBPOZNYTE5PS4PE5OJZM/
Code of Conduct: http://python.org/psf/codeofconduct/
