[Distutils] status check on PEP 517
Alex Grönholm
alex.gronholm at nextday.fi
Sat Jul 29 18:00:53 EDT 2017
Daniel Holth kirjoitti 30.07.2017 klo 00:58:
>
> 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.
>
What package manager are you referring to?
>
> On Sat, Jul 29, 2017, 17:50 Alex Grönholm <alex.gronholm at nextday.fi
> <mailto: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 <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/4268c909/attachment-0001.html>
More information about the Distutils-SIG
mailing list