[Distutils] PEP 517: Bootstrapping setuptools

Daniel Holth dholth at gmail.com
Tue Aug 22 09:23:42 EDT 2017


Isn't this a special case of needing . on sys.path when building a package?
Then the same version of setuptools that is being packaged builds itself.

I've experimented with a different kind of bootstrapping where pip installs
setuptools on demand when the first setuptools requiring package is built.
You kindof need pkg-resources as a separate package for this. It is a cool
parlor trick but it's simpler and harmless to just always install
setuptools like we do.

On Tue, Aug 22, 2017, 09:14 Jim Fulton <jim at jimfulton.info> wrote:

> 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
> _______________________________________________
> 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/20170822/fcd41ccc/attachment-0001.html>


More information about the Distutils-SIG mailing list