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

[Daniel Holth]

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 <vinay_sajip at yahoo.co.uk>
> wrote:
> > Éric Araujo <merwok <at> 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
> distribute_setup.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>