There exist many systems in the real world that require building everything from source. Setuptools circular dependencies broke all of them (and any circular build time dependency would). The one I'm most familiar with has special cased a bootstrap C compiler and a very limited shell with a few other builtins and then the very first thing it does is build the "real" C compiler, shell, etc from source and then throws away the bootstrap scripts.
Anything that has a circular dependency is going to force those systems to special case them as well. Most of them will just avoid those packages if they can at all help it because random Python packages do not rise to the level of special as gcc does. Sent from my iPhone > On Jul 29, 2017, at 7:19 PM, Nathaniel Smith <n...@pobox.com> wrote: > > It's true that this is problematic for packages that don't have wheels, but > flit and click are both pure python packages with wheels available, so I > don't think there's any problem here in practice. (In fact flit currently > uses flit as its build system, and depends on at least one other package that > uses flit as its build system.) > > > I thought the big problem with setuptools unvendoring was that we don't > currently have isolation for build requirements, so there was interference > between what setuptools wanted and what other packages wanted? PEP 517 > doesn't have that problem because build backends are installed into their own > little quasi-virtualenv. Or am I wrong?
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
