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.gronh...@nextday.fi <mailto:alex.gronh...@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.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: Donald Stufft kirjoitti 29.07.2017 klo 23:47:On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <n...@pobox.com <mailto:n...@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@python.org <mailto:Distutils-SIG@python.org> https://mail.python.org/mailman/listinfo/distutils-sig_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org <mailto:Distutils-SIG@python.org> https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
