[Distutils] status check on PEP 517

[Daniel Holth]

Yes vendoring would be a solution but it's too soon to say whether the
problem is significant. Setuptools and pip have a different problem which
is that the package manager isn't available yet. In pep517 the package
manager is available.

On Sat, Jul 29, 2017, 17:50 Alex Grönholm <alex.gronholm at nextday.fi> wrote:

> 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>
> wrote:
>
>> Donald Stufft kirjoitti 29.07.2017 klo 23:47:
>>
>>
>> On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <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.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>> _______________________________________________
>> 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/20170729/2f0c7bdd/attachment-0001.html>