[Distutils] Comments on PEP 426

[M.-A. Lemburg]

On 03.09.2013 23:57, Paul Moore wrote:
> On 3 September 2013 22:20, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> 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.
>>
> 
> I'm curious about this possibility. One thing that would ease
> experimentation in this area, and which has certainly been discussed
> elsewhere in this thread, would be if there was a clearly defined set of
> setuptools facilities that are missing from distutils, and which the
> "modern infrastructure" relies on. Off the top of my head, the following
> items would definitely be needed:
> 
> 1. An extension to the install command to supply a list of the installed
> files (the --record feature of setuptools)

This already exists in distutils' install command.

> 2. A bdist_wheel command

This is not part of setuptools, but yes, this should be added
as well.

> 3. Updates to the install (or maybe bdist_egg) commands to emit Metadata
> 2.0 and dist-info metadata

Should be easy to do (mostly copy&paste).

> 4. An install_scripts command that created script wrappers from metadata
> (may not be needed if the only supported route to install is via wheels)

Adding new commands is really easy in distutils, so that's
not much of a problem either: distutils has a "cmdclass" mechanism
which allows to easily register new commands or override existing
command classes.

We've been using this in mxSetup.py to customize distutils
commands and add new commands such as an autoconf mechanism
in the build process, a C library build process (implementing
the "./configure; make" dance), bdist_prebuilt or uninstall.

> To be honest, these extensions do seem relatively achievable. But I don't
> know if they are complete - can the advocates of setuptools clarify what
> facilities of setuptools are needed beyond these (with an indication of
> where they are used in the build toolchain).
> 
> There are other features of setuptools that I can see would be relevant
> (for instance, version parsing and requirement checking) but these seem to
> me to be more in the nature of utility library features than distutils
> enhancements per se. I'd fully expect that such code could easily be
> extracted from setuptools (indeed, it may be that all of that code is
> isolated in pkg_resources already) without needing any of the distutils
> monkeypatching/extensions.
> 
> It may be that such an approach is reinventing the existing wheel that is
> setuptools, and indeed it may never go anywhere - but it is an interesting
> alternative train of thought.

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.

I guess that's what the suggestion is all about: avoiding
reinventing the wheel, endless discussions and instead going
for standard software refactoring techniques.

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