There are two proposals to add pluggable build systems to Python sdists, and one of them will probably be implemented. You add a pyproject.toml to the root of your sdist, which the installer uses to install dependencies that setup.py itself needs to run. Second, you also tell pip which build system you are using, once you have done that, setup.py is no longer necessary - instead, pip could install and then invoke flit for example.
This isn't quite the situation you've outlined as setuptools will likely continue to have all its features. Instead, packages that don't use setuptools will also proliferate. It causes about the same problem for buildout without breaking older packages. In this scenario buildout will need to be able to install wheels however it wishes to do so because that is the output of the pluggable build system. I don't have advice for you on the implementation, except perhaps it could call out to pip. On Tue, Aug 16, 2016 at 12:59 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> wrote: > >> >> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida < >> 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. > > 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? > > 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. > > Regards, > > Leo > _______________________________________________ > 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
