[Distutils] Comments on PEP 426

[M.-A. Lemburg]

On 04.09.2013 01:51, Nick Coghlan wrote:
> On 4 Sep 2013 07:20, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>
>> On 31.08.2013 17:56, Nick Coghlan wrote:
>>> setuptools definitely has its issues, but it's still substantially
> superior
>>> to distutils, and has the critical virtue of behaving the *same* in all
>>> currently supported versions of Python. Consistency across platform
>>> versions is something you really want in a build tool, and is something
> a
>>> standard library module like distutils can never provide. As one of the
>>> most conservative Linux vendors, even Red Hat has acknowledged this key
>>> point by creating the Red Hat Developer Toolset to provide a more
>>> consistent build experience across different RHEL versions. Microsoft
> (with
>>> Visual Studio) and Apple (with XCode) have long worked the same way.
>>
>> I think you're overestimating the usefulness of setuptools here.
>>
>> setuptools only extends distutils in various ways, it doesn't
>> replace it. And it doesn't do a good job at extending it, since
>> it monkey patches distutils in areas where monkey patching
>> is not necessary (*).
>>
>> distutils does provide a pretty straight forward way to extend it,
>> adding new commands to it and new options to existing commands.
>> I've been extending distutils for many many years in mxSetup.py
>> (which is part of egenix-mx-base). It's been working great and
>> I only rarely had to revert to monkey patching in order to get
>> something implemented.
>>
>> IMO, a much better way forward would be to integrate useful setuptools
>> changes right back into distutils, so that the monkey patching
>> no longer happens and python-dev can officially bless those
>> set of changes.
>>
>> BTW: I'm not sure where you get the idea from that setuptools
>> behaves the same across Python versions or platforms. It simply
>> inherits the distutils changes in each version and thus exhibits
>> the same problems (if any) that you see with distutils itself.
>>
>> (*) Monkey patching is necessary in a few places, but most of those
>> could be fixed by splitting out method code into new methods which can
>> then be overridden to provide the new functionality. Note that
>> this is a classical problem with OO code, there's nothing special
>> here w/r to distutils.
> 
> Sure, it's *possible* someone could publish a "better setuptools" that
> avoids unnecessary monkey patching, leaves out easy_install and separates
> pkg_resources out into its own distribution.
> 
> However, setuptools, for all its flaws, already clears the "good enough"
> bar in most cases, at least as far back as 2.6 (and likely earlier). Any
> new standards are going to have to be supported in setuptools *anyway* due
> to the number of projects that rely on it explicitly for the opt-in
> features like dependency declarations and entry points, so it seems
> expedient to me to avoid duplicating that effort.
> 
> There are also existing projects like bento with a setup.py that can cope
> with vanilla distutils *and* with setuptools, but may not cope with a new
> setuptools replacement that does things a bit differently again.
> 
> The recommendation to use setuptools and the requirement for all
> distributions to at least *tolerate* setuptools being imported into the
> same process as their setup.py is an entirely pragmatic one in order to
> bootstrap the migration to the next generation dependency management system
> by using the *current* dependency declaration system.

The idea is to integrate setuptools extensions to distutils
back into vanilla distutils, so that you don't need to do
monkey patching and change distutils in wasy that break the
regular distutils extension mechanisms.

This may break a few extensions for Python 3.4, but not many.
Most distributions use plain distutils or plain setuptools
without any changes. Of the ones that use setuptools the most
dominantly used features are being able to build eggs and
requirement tracking.

The ones extending distutils (with or without setuptools
monkey patching enabled) will most likely already support
most of the setuptools hacks, simply because it's been
difficult to ignore setuptools for at least the last
5 years. The few that don't will have to get updated
after such a change.

We need to get rid off hacks like setuptools if we ever
want to see light at the end of the packaging tunnel.

-- 
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/