Re: buildout and pip and wheel "Add support for installing wheels" https://github.com/buildout/buildout/issues/144
It's been awhile since I've worked with buildout (for Zope 2, Plone, AppEngine zipimports). This reads #egg= links from pip requirements files: - https://github.com/collective/collective.recipe.pip/blob/master/collective/recipe/pip/__init__.py This installs packages with buildout and pip (instead of zc.recipe.egg) into the eggs/ directory. IDK if it supports wheels? (it specifies --egg): - https://github.com/k4ml/mk.recipe.pip/blob/master/mk/recipe/pip/__init__.py ... this builds a usable merged namespace with symlinks to eggs: - https://github.com/collective/collective.recipe.omelette/ On Tuesday, August 16, 2016, Daniel Holth <dho...@gmail.com> wrote: > 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 > <javascript:_e(%7B%7D,'cvml','leoroch...@gmail.com');>> wrote: > >> Spinning this off into its own thread... >> >> On 16 August 2016 at 13:10, Donald Stufft <don...@stufft.io >> <javascript:_e(%7B%7D,'cvml','don...@stufft.io');>> wrote: >> >>> >>> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida < >>> leoroch...@gmail.com >>> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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
