[Distutils] Extracting distutils into setuptools

xoviat xoviat at gmail.com
Sun Oct 1 13:53:22 EDT 2017


After thinking again about that possibilities that we've discussed here, I
realized that a previously proposed alternative would eliminate external
build-time dependencies and allow us to merge setuptools with distutils: an
"ensuresetuptools" module. This was proposed by @zooba, but basically the
idea would be to bundle a wheel of setuptools (setuptools is
py2.py3.none-any) that Python could install without requiring network
access or other modules. If distutils is required during the build process,
then this idea should conform to all of the requirements proposed here and
take distutils off of the CPython release schedule.

Although it may seem more complicated at first, once implemented,
maintenance from the CPython side would be minimal (a bot could update the
wheel, although I'm not sure whether this is done with ensurepip), there is
precedent for this (with ensurepip), end-users could continue to use
distutils without any modifications to their scripts (ensuresetuptools
could be run during the installation process, and even if it isn't, then a
single command line could install distutils/setuptools), and it would allow
simplified setuptools maintenance (no monkeypatching).

2017-09-30 20:14 GMT-05:00 Donald Stufft <donald at stufft.io>:

> I think that the CPython builds a python executable, then uses that built
> executable to finish the installation.
>
>
> On Sep 30, 2017, at 9:11 PM, xoviat <xoviat at gmail.com> wrote:
>
> It would be nice to know whether this information is correct, or whether I
> hold an invalid belief.
>
> 2017-09-30 20:09 GMT-05:00 xoviat <xoviat at gmail.com>:
>
>> I have personally not built Python myself (though I've built many an
>> extension), but what I can say is that I got the idea from Larry Hastings.
>> According to him (this if for the Gilectomy fork):
>>
>> "Second, as you hack on the Gilectomy you may break your "python"
>> executable rather badly. This is of course expected. However, the python
>> Makefile itself depends on having a working local python interpreter, so
>> when you break that you often break your build too."
>>
>> 2017-09-30 19:59 GMT-05:00 Donald Stufft <donald at stufft.io>:
>>
>>>
>>>
>>> On Sep 30, 2017, at 3:52 PM, xoviat <xoviat at gmail.com> wrote:
>>>
>>> I don't think CPython needs to bundle all of its build-time
>>> dependencies. That principle doesn't really apply to other Python programs
>>> nor most other programs in general. AFAIK, CPython already has a build-time
>>> dependency on another, external, Python, so it wouldn't be too much to
>>> require the external Python to have setuptools installed with something
>>> like pyproject.toml (other programming languages usually bootstrap
>>> themselves with previous versions of the language along with some
>>> associated build tools).
>>>
>>>
>>> As far as I can tell, CPython does *not* have a build time dependency on
>>> having Python available. I just spun up a bare alpine linux container and
>>> compiled CPython `master` branch on it. As far as I can tell the only
>>> Python that exists in this container is the one I just compiled.
>>>
>>> That means that in order for CPython to depend on distutils to build as
>>> you indicate, it would also need to start depending on an existing version
>>> of Python being available. I don’t think that’s a great idea. I think
>>> Python should not depend on Python to build.
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171001/8b909a35/attachment.html>


More information about the Distutils-SIG mailing list