[Distutils] PEP 517: Bootstrapping setuptools

[Jim Fulton]

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

Jim


> 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
http://jimfulton.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170822/39279f79/attachment.html>