> On Aug 16, 2016, at 12:58 PM, Leonardo Rochael Almeida <leoroch...@gmail.com> > wrote: > > Spinning this off into its own thread... > > On 16 August 2016 at 13:10, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > >> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida <leoroch...@gmail.com >> <mailto:leoroch...@gmail.com>> wrote: >> >> Specifically, buildout right now has setuptools as its only dependence, and >> buildout uses it to locate, download and build sdist dependencies, or >> directly download and use .egg dependencies, which are important for Windows >> platforms in the communities that use buildout and depend on compiled >> extensions. > > > Ah, I knew I was forgetting something. I think we should hold off on > preventing egg uploads until setuptools can download and install wheels. > > Which brings us to a question that I'm meaning to ask for a while. > > It looks like we're close to removing all mentions of setuptools in pip. When > this happens, it looks like pressure is going to start to mount on setuptools > to drop the ability to install packages and limit itself on being just a > build tool. > > It makes sense that it should be so, considering that there would be no > incentive to keep around two distinct implementations of how to locate, > download and install stuff, one in pip (or whatever library pip uses for > locating and installing packages) and another in setuptools.
So one of our end goals here (and why we’re so stuck on standards for everything, and not ad hoc things) is to make it entirely possible to have multiple distinct implementations of any part of the tool chain without having to try and copy each other’s features/implementation details to work. There’s one standard for what is correct and as long as you follow that, then you should work. With that in mind, I certainly hope to get to a point where at the very least, setuptools make the conscious choice to continue to implement these features, rather than needing to do it because pip depends on it. Whether it makes sense for setuptools to continue to support them or not is something that the setuptools devs (particularly Jason) is going to be better suited to answer, but for my own opinion I hope we can get to a point that setuptools is just a build tool. > > In this future, I can imagine setuptools will simply complain loudly when the > packages it requires to do its work are not installed yet, perhaps with a > plugin mechanism for allowing another package to automatically resolve and > installing packages, (like today setuptools-git extends setuptools to > recognize files from git to be included in a package). > > And people will promptly write a pip implementation of this plugin (or > whatever it is that pip will use as a library to do it)... thereby inverting > the dependency between setuptools and pip. > > When this future arrives, buildout will be out of a mechanism for locating, > downloading and installing packages (not counting old versions of setuptools, > of course). > > Questions: > > 1. Is the future outlined above considered likely? I suspect that maybe, at some point it might be, but I think that setuptools will likely keep it’s support for these things for a good long while to avoid breaking things for people. At least until a satisfactory answer for what someone who is currently using setuptools should use emerges. > > 2. If this future arrives, what package should buildout be ported to use? It > should provide: > > * The ability to locate packages and their versions, resolve their > dependencies, and download them, whether they're sdists or wheels (or eggs, > while we still have them) > * Install each package separately into it's own directory that, if added to > `sys.path`, allows this same package (or perhaps another one) to read > information from entry points so that buildout can locate its own extensions > and install console scripts. > So you have a few choices, right now you can use pip in a subprocess (pip does not expose a programmatic API) or continue to use setuptools. One of the things we’ve been trying to do with pip is instead of adding/exposing parts of pip via a programmatic API, is to instead extract them out into their own dedicated libraries that then pip consumes. This has the benefit that setuptools can depend on those things, instead of pip itself, but also that other people can come along and piece meal use the pieces that make sense for them. If someone has a great new idea for a pip-killer that does everything better, then they can do that, and reuse these libraries to help make their thing better right out of the starting gate. So we could work on that effort too, I think the main thing holding it back is both developer time, as well as solid use cases so we can design the API around them. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
