[Distutils] Extracting distutils into setuptools

[Chris Barker - NOAA Federal]

>>>> distutils works fine for its original purpose (building components for
>>>> the system Python in Linux distros),

What does Linux have to with it? In the eagle days, I found it most
helpful for Windows, actually. And it's very helpful for OS-X as well.

It was also great for pure python bundling and installing.

But regardless of original intent, it's clear that distutils has not
turned out to be as cleanly extendible as is needed.

Setuptools has its issues as well -- personally it has always driven
me crazy with its mingling of run-time vs build-time vs install time
functionality.

I think it would be helpful to be explicit about the final goals
before talking about whether and how to fork distutils.

What I'd love to see is a build tool that is compatible with the
"modern" packaging paradigm-- pip, pypi, wheels. ( and other systems
like rpm, conda, ....)

Essentially setuptools without the cruft. ( no easy install, pkg_resources, ...)

This could be maintained as a third party package, like the current
setuptools. If/when it becomes ubiquitous, an "ensure" style module
could be added to the stdlib.

So how do we get there? I would think a fork and merge of both
setuptools and distutils would make sense. Preserve the building part
of the API, so folks could simply replace the import line an their
setup.py files to use the new tool.

Distutils and setuptools remain in maintainable only mode for probably
a long time :-(

-CHB



>>>> so we still need to avoid
>>>> breaking that. setuptools is only essential if you want full support
>>>> for modern *Python* level packaging features (PEP 376 install
>>>> metadata, venv compatibility, wheel files, etc), and a lot of Linux
>>>> system components simply don't worry about those things, and rely on
>>>> their system level equivalents instead (e.g. the RPM/deb databases,
>>>> chroots and containers, RPM/deb files)
>>>>
>>>> However, what *could* be interesting is a proposal to move distutils
>>>> to the "ensurepip" model, where rather than maintaining distutils
>>>> directly as part of CPython, the CPython build process instead runs
>>>> setuptools/distutils from a bundled wheel file. Doing that would
>>>> entail having setuptools actually start installing a copy of distutils
>>>> into site-packages: older CPython releases would ignore it by default
>>>> (since the stdlib version would shadow it), while 3.7+ would offer
>>>> either "python3 -m ensuredistutils" or "python3 -m ensuresetuptools"
>>>> (bikeshed to be painted via the PEP process) to install the
>>>> setuptools-provided version.
>>>>
>>>> I'm not claiming actually doing that would be particularly easy - I
>>>> just think it's the most viable path to get us away from the current
>>>> version coupling between the build infrastructure in distutils and the
>>>> runtime support infrastructure in the rest of the standard library,
>>>> and to avoid maintaining two distinct copies of distutils indefinitely
>>>> (one in the stdlib, one in setuptools).
>>>>
>>>> That approach wouldn't even entail any *new* bundling at the CPython
>>>> level, as while it's currently formally an implementation detail
>>>> (pending potential removal in a post-PEP-517 world), setuptools is
>>>> already bundled as part of the support infrastructure for ensurepip:
>>>> https://github.com/python/cpython/tree/master/Lib/ensurepip/_bundled
>>>>
>>>> Cheers,
>>>> Nick.
>>>>
>>>> --
>>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>> _______________________________________________
>>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>>
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>