On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <njs@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). 

—
Donald Stufft