On 04.09.2013 09:27, Paul Moore wrote: > On 4 September 2013 08:13, M.-A. Lemburg <m...@egenix.com> wrote: >> It's not about reinventing the wheel, it's taking the good bits >> from setuptools and moving them into distutils to make them >> standard for Python 3.4+, allowing setuptools to stop monkey patching >> distutils and extensions to stop relying on a setuptools >> patched distutils. > > Personally, I was thinking about externally packaged extensions to > distutils - a sort of "setuptools lite" if you like. I think Antoine > has a point in that people do tend to keep suggesting "updating > distutils" forgetting that there is no way that is ever going to > happen. To my knowledge, no core committer is willing to apply patches > to distutils[1] and the track record of someone external getting core > privs and trying to apply distutils changes consists of Tarek, who > despite all his efforts didn't manage to get anywhere.
The reason for this is not that no one wants to apply such patches, it's that distutils has been put on a moratorium for quite some time now - mostly due to the distutils2/packaging efforts and the concerns about backwards compatibility. We can lift that moratorium and start to move forward again. Note that just moving features from setuptools into distutils will not cause major breakage. If we are serious about this, we do have to accept some breakage, but it will be minimal. Related to the suggestion to have distutils extensions, we could also add a mechanism to make the cmdclass feature in distutils, I mentioned, easier to use and provide a way which allows distutils extensions to easily register themselves. >> I guess that's what the suggestion is all about: avoiding >> reinventing the wheel, endless discussions and instead going >> for standard software refactoring techniques. > > To my mind the biggest issue (and again, I'm with Antoine here - > people keep forgetting this) is that there are no defined API specs to > work to. You can't implement "just the important bits" of setuptools > without knowing what those bits are, and what the interface to them > is. I don't quite follow you there. setuptools does come with documentation and the code is available to be read and reused. The situation is similar for distutils itself. Most of the details are laid out in the code. You just need to take a bit of time and learn the concepts - which is not all that hard. > I do suspect that the issue is not so much forgetfulness as optimism - > people keep hoping that we can find a clean and simple solution, in > spite of the overwhelming evidence that it'll never happen. But maybe > that's just me being optimistic as well :-) I think we've walked down too many dead ends by now to keep thinking that someone somewhere will come up with the one and only solution to it all. distutils itself was an effort in that direction. Before distutils, the only mechanism we had was Makefile.pre.in. distutils isn't prefect, but it works mostly and has been working for quite some time now. Given that its in the standard library it's hard to evolve - just like any code that makes it into the stdlib. I think it's about time that we allow some minimal breakage to get rid off hacks like setuptools and first class some, or even all, new commands and features setuptools adds to distutils. > [1] For what are probably very good reasons - it seems like it's a > sure-fire route to instant burnout :-( True. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
