[Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3) (original) (raw)

Daniel Holth dholth at gmail.com
Fri Feb 15 20:33:02 CET 2013

On Fri, Feb 15, 2013 at 12:27 PM, Erik Bray <erik.m.bray at gmail.com> wrote:

On Sun, Feb 3, 2013 at 5:24 PM, Vinay Sajip <vinaysajip at yahoo.co.uk> wrote: > Éric Araujo <merwok netwok.org> writes: > >> Looks like we agree that a basic tool able to bootstrap the packaging >> story is needed :) > > Agreed. Just because distutils can't easily/reliably build things that are > better built with SCons/WAF/tup/whatever, doesn't mean that we shouldn't have > the ability to build pure-Python distributions and distributions including C > libs and extensions, with the ability to extend easily by third-party tools. It > just needs to be done in a way which is easy to build on, so the included > battery stays small and simple. Easier said than done, I know :-) > > Regards, > > Vinay Sajip

Sorry to revive an old-ish discussion--I'm just catching up on things. But I just wanted to add that distutils is still pretty okay for building reasonably complex projects. Although it does not rise to the level of complexity of Numpy or SciPy, the Astropy project (https://github.com/astropy/astropy) has managed to put together a pretty nice build system on top of mostly-plain distutils (it does use distribute but primarily just for 2to3 support).

This has necessitated a number of hacks to overcome shortcomings and bugs in distutils, but most of those shortcomings could probably be fixed in distutils within the framework of a slightly lifted freeze. But in any case I haven't found it worthwhile to switch to something like bento when the batteries included in the stdlib have been mostly Good Enough. Having fewer installation dependencies has also made it significantly easier for non-advanced users to install. Even the distribute requirement doesn't add too much overhead, as most users have it on their systems by default now, and for those who don't distributesetup.py works okay. TL;DR, strong -1 on the stdlib "getting out of the build business". Also as I think Nick already mentioned one of the wins of Setup-Requires-Dist is to have a standard way to bring in extra build requirements (such as bento) so if we have better support for a feature like that it's not necessary to "bless" any preferred tool.

Distutils is not really going away. We need it to build the existing 28,000 packages. However empirically it seems if you try to write a significant extension to or improvement of distutils then you are likely to get burnt out and switch careers.

Instead of literally killing distutils we hope to make it very easy to use other build tools when you need them and not use any build tools at all when you don't. As a thought experiment: what if one of those third party build tools hosted on pypi was distutils itself? What would you need to do to make that happen?

The packaging peps PEP-376 and so on are brilliant because they are simple enough to be implemented twice. If we had better ways to separate interface from implementation in Python I'd like to see two of whatever else we come up with for packaging. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130215/b78fd27c/attachment-0001.html>

More information about the Python-Dev mailing list