[Distutils] status check on PEP 517
Alex Grönholm
alex.gronholm at nextday.fi
Sat Jul 29 17:37:32 EDT 2017
Donald Stufft kirjoitti 29.07.2017 klo 23:47:
>
>> On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <njs at pobox.com
>> <mailto:njs at pobox.com>> wrote:
>>
>> I guess the most obvious example of when this would occur is: suppose
>> click switches to using flit for builds, and then flit switches to
>> using click for command line parsing. Now there's a bit of a chicken
>> and egg problem where 'pip install click' will end up importing flit
>> with the click source tree on the path, and this tree of course
>> contains a directory named 'click', so unless special measures are
>> taken flit will end up importing the code it's trying to build.
>>
>> But of course this can happen for lots of reasons; most packages have
>> names that you wouldn't expect to randomly encounter at the root of a
>> source tree very often, but with 100,000+ packages on pypi I expect
>> it will happen eventually.
>>
>> This doesn't happen with setuptools because setuptools traditionally
>> has few or no dependencies, but obviously we're changing that; the
>> whole idea here is that now your build system has full access to pypi.
>
>
> This is something to be discouraged anyways, because it creates a sort
> of broken situation (the same situation that setuptools itself had).
> The problem is that if you’re starting from only sdists, you have a
> circular dependency that cannot be broken. You can’t build click,
> because click requires flit, but you can’t install flit, because flit
> requires click. The only way to fix this is to either have an already
> built wheel that you can use (which obviously was either built with a
> flit that didn’t require click, or a click that didn’t require flit,
> or it’s provenance can be traced back to that) or do some hacks that
> will hopefully resolve the situation good enough to get your first
> wheel built.
>
> Setuptools tried to depend on things, and it broke shit for a lot of
> people because of this. You basically can’t depend on anything as a
> build system that uses you as a build system. You can only depend on
> things that use other, different build systems in the entire
> dependency tree. Likely the best thing for build systems to do is
> either have no dependencies, or to have minimal dependencies that
> promise to only use setuptools (or another build tool, which one
> doesn’t matter, just as long as it has no dependencies) forever (and
> have setuptools or this other build tool promise to never take a
> dependency).
Or vendorize their dependencies? To me it seems unrealistic for a build
system to have no dependencies at all. Or perhaps this is exactly what
you meant :)
>
> —
> Donald Stufft
>
>
>
>
>
> _______________________________________________
> 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/20170730/2ef1e56f/attachment.html>
More information about the Distutils-SIG
mailing list