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. ">

(original) (raw)

On Fri, Feb 15, 2013 at 12:27 PM, Erik Bray <erik.m.bray@gmail.com> wrote:
On Sun, Feb 3, 2013 at 5:24 PM, Vinay Sajip <vinay\_sajip@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
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.