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 <[email protected]
<mailto:[email protected]>> wrote:
Donald Stufft kirjoitti 29.07.2017 klo 23:47:
On Jul 29, 2017, at 12:46 PM, Nathaniel Smith <[email protected]
<mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - [email protected]
<mailto:[email protected]>
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
