[Distutils] Future of setuptools and buildout
Wes Turner
wes.turner at gmail.com
Fri Aug 19 00:29:43 EDT 2016
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 <dholth at 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 <
> leorochael at gmail.com
> <javascript:_e(%7B%7D,'cvml','leorochael at gmail.com');>> wrote:
>
>> Spinning this off into its own thread...
>>
>> On 16 August 2016 at 13:10, Donald Stufft <donald at stufft.io
>> <javascript:_e(%7B%7D,'cvml','donald at stufft.io');>> wrote:
>>
>>>
>>> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida <
>>> leorochael at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','leorochael at 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 at python.org
>> <javascript:_e(%7B%7D,'cvml','Distutils-SIG at python.org');>
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160818/26c9710a/attachment.html>
More information about the Distutils-SIG
mailing list