[Distutils] Comments on PEP 426

[Nick Coghlan]

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.

Cheers,
Nick.

>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Sep 03 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130904/169995b0/attachment-0001.html>