[Distutils] Comments on PEP 426

[M.-A. Lemburg]

On 04.09.2013 09:27, Paul Moore wrote:
> On 4 September 2013 08:13, M.-A. Lemburg <mal at 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/