[Distutils] PEP 517: Bootstrapping setuptools

xoviat xoviat at gmail.com
Mon Aug 21 17:39:20 EDT 2017


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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170821/c2168a91/attachment-0001.html>


More information about the Distutils-SIG mailing list