[Distutils] Extracting distutils into setuptools

[xoviat]

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

There's no need to even replace the line in setup.py. Setuptools currently
has the full capability to override the distutils namespace when it's
imported first. I think if we extract distutils into setuptools, it's not
difficult to list setuptools in install_requires or otherwise on Python 3.7
and above. And I think it will eventually be better for setuptools because
the monkeypatch can be avoided. This might even solve the bootstrapping
problem.


2017-09-28 11:08 GMT-05:00 Chris Barker - NOAA Federal <
chris.barker at noaa.gov>:

> >>>> 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
> >
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170928/dbb40f0b/attachment-0001.html>