[Distutils] PEP 517: Bootstrapping setuptools

Jim Fulton jim at jimfulton.info
Tue Aug 22 09:13:29 EDT 2017

On Mon, Aug 21, 2017 at 5:39 PM, xoviat <xoviat at gmail.com> wrote:

> This statement comes from something that Donald said:
> > The unvendoring means that setuptools and the project code are now
> competing over who gets to define what an acceptable version is for these
> libraries to be installed with.
> As if this isn't going to be true for any other build system, and
> setuptools won't at all be in any way special in a PEP 517 world. So you
> are always going to have complaints about "well build system X required a
> newer version but my project requires an older version" when the real
> problem is that people are requiring an older version/ projects do not have
> a stable API.

This boils down to implementation details. <shrug>  pip dealt with this
issue and buildout stumbled because of differences in the way they managed
their paths.  Buildout could have coped (eventually).


> 2017-08-21 16:27 GMT-05:00 Jim Fulton <jim at jimfulton.info>:
>> On Mon, Aug 21, 2017 at 5:17 PM, xoviat <xoviat at gmail.com> wrote:
>>> Of course, to be frank, the principle failure with this plan is that
>>> third-party tools (buildout, os packagers) will not be compliant with PEP
>>> 517 even after it is adopted, and will then complain about having to update
>>> their build systems.
>> I don't understand this statement. If buildout needs to be compliant, it
>> will be (eventually).  I can imagine a future where everything is
>> distributed with wheels and buildout wouldn't need to build anything.
>> Jim
>>> 2017-08-21 16:05 GMT-05:00 xoviat <xoviat at gmail.com>:
>>>> Previously, the attempt to move setuptools off of vendored dependencies
>>>> failed because it was not done correctly: install_requires was set to the
>>>> vendored dependencies but not setup_requires, which would have been
>>>> required to correctly specify dependencies. However, setup_requires would
>>>> have introduced circular dependencies that are impossible to correctly
>>>> resolve, so that would have simply shifted an impossible problem onto pip.
>>>> The principle issue then, is that setuptools requires setuptools to
>>>> build itself. And although, this problem was previously not worth solving
>>>> because of 'setup.py install', it is now not a difficult problem to solve
>>>> if we rethink slightly what should be included in the setuptools
>>>> respository:
>>>> - Rather than re-generating egg_info on each setup.py invocation, we
>>>> can cache dist-info in the setuptools respository.
>>>> - We can implement a simple entry_points script that updates dist-info
>>>> based on the contents of setup.py, which is only runnable of course after
>>>> setuptools is installed
>>>> - We can implement the reference build backend for setuptools: simply
>>>> copy the files and dist-info into a new compliant zip archive
>>>> Viola! Setuptools is no longer required to build setuptools, and the
>>>> installation process is fully compliant with Python PEPs.
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>> --
>> Jim Fulton
>> http://jimfulton.info

Jim Fulton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170822/39279f79/attachment.html>

More information about the Distutils-SIG mailing list