Pip has to vendor its dependencies primarily because it can't pip install them. Not the same problem as build systems.
On Sat, Jul 29, 2017, 18:00 Alex Grönholm <alex.gronh...@nextday.fi> wrote: > 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> > 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> >> wrote: >> >>> Donald Stufft kirjoitti 29.07.2017 klo 23:47: >>> >>> >>> On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <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.orghttps://mail.python.org/mailman/listinfo/distutils-sig >>> >>> >>> _______________________________________________ >>> Distutils-SIG maillist - 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
