[Distutils] status check on PEP 517

[Alex Grönholm]

Daniel Holth kirjoitti 30.07.2017 klo 00:48:
>
> I think the proposal is that flit depends on click depends on flit and 
> neither one has a wheel and must be built from sdists. Then you have a 
> circular build problem. So don't do that. I put this in the same 
> category as accidentally conflicting with a stdlib module; it is 
> confusing when it happens but it's also fairly avoidable.
>
Sure but vendorizing the dependencies would work around the problem, 
yes? Like how setuptools does?
>
> On Sat, Jul 29, 2017, 17:38 Alex Grönholm <alex.gronholm at nextday.fi 
> <mailto:alex.gronholm at nextday.fi>> wrote:
>
>     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 <mailto:Distutils-SIG at python.org>
>>     https://mail.python.org/mailman/listinfo/distutils-sig
>
>     _______________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto: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/dc2cb0d4/attachment-0001.html>