[Distutils] status check on PEP 517

[Alex Grönholm]

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>