[Distutils] The problem with Setuptools on Python 3.

Tarek Ziadé ziade.tarek at gmail.com
Mon Apr 20 17:02:26 CEST 2009


On Mon, Apr 20, 2009 at 4:36 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Tarek Ziadé wrote:
>>
>> no it doesn't.  it's a generic tool to extend a command using plugins.
>>
>
> OK.
>
>>
>> Sorry, it's too easy to say "it sucks, scratch it and re-do it" ;)
>>
>
> Yes, it is easy to say it sucks, but I am not saying that out of thin
> air. Refactoring works if the general API is ok - but that's not the
> case with distutils. As a data point, several people have tried to add
> features to distutils in numpy extensions, and I went much further than
> anyone else by bypassing distutils entirely, replacing the build_*
> commands by scons. The core codebase is ten times smaller than the
> original code it replaces (numpy.distutils is around 10 000 LOC, like
> distutils itself).
>
> I agree that in the short term, distutils should be improved, but in the
> long term, I don't see anything which would be both a significant
> improvement while staying backward compatible with distutils, if only
> because so many setup.py files depend on implementation details of
> distutils.

In the short term, Distutils needs to be a better citizen when people
wants to extend it, so they can do it without re-writing everything.

You have this experience of "pain", share it through real use cases.

In the long term Distutils needs to be *smaller* and to provide
a playground for other tools. in particular for all the tools that need to
build a binary package on a given platform.

(We can't keep those platform specific tools in the scope of distutils)

And the work done on various PEPs (all links at the top of
http://wiki.python.org/moin/Distutils)
are aiming to this goal.

What about organizing a sprint soon btw, so we don't loose Pycon efforts ?

-- 
Tarek Ziadé | http://ziade.org


More information about the Distutils-SIG mailing list