[Distutils] Annoucing distribute project

Tarek Ziadé ziade.tarek at gmail.com
Thu Sep 25 18:58:09 CEST 2008

On Thu, Sep 25, 2008 at 6:31 PM, Phillip J. Eby <pje at telecommunity.com>wrote:

> At 07:52 AM 9/25/2008 +0200, Tarek Ziadé wrote:
>> Anyway, that sounds great indeed. But since setuptools is not on the top
>> of your priority sometimes (you said it wasn't, and we could see it wasn't),
>> are those people blessed to release it as well ?
> I don't see a problem with that, although the actual release process itself
> is nearly 100% automated.  (See the 'release.sh' file.)  Assuming that there
> is a releasable distribution in SVN, it takes maybe 15 minutes for me to cut
> a release and bump the version, if that long.  (And it could probably be
> further automated.)
> By the way, you'll notice if you inspect the distutils-sig archives
> carefully, I'm *extremely* responsive when people post questions or report
> bugs that haven't been previously answered or fixed.  I simply don't have a
> lot of time to drive new development.
> There are few people qualified to do the design vetting and testing that
> needs to happen for major new features to be added atop the existing code
> base, and that's 100% independent of any forking.  If the persons existed
> who could actually do this, there is no technical reason why they couldn't
> have been doing it prior to the fork.  (Which leads me to believe that they
> don't exist or have the time, and thus, the fork will not actually help
> anything.)
> Personally, I would rather see not a "fork", but development of an entirely
> new disutils replacement, and then not worry at all about backward
> compatibility at the setup.py level.  Apart from the pkg_resources module, I
> would treat setuptools and distutils as legacy infrastructure, and explore
> better ways to build and manage distributions (including eggs).
> If I had the time, that's what I'd be doing.

That makes a lot of sense, working on a distutils replacement would be more
constructive you are right. But we would then need to work hard to migrate
existing projects. This is quite scary.

>  I mean, if we have a clear roadmap of the next releases of setuptools,
>> with dates, and if you are unable to release it yourself, can we count on
>> them to do so ? If so I'd be more than happy to stop that fork, and to
>> continue happily to work in the bug tracker if I have a visible roadmap.
> Feel free to create such a roadmap; as you can see, I do have time to
> answer a few emails and give feedback.  And if somebody responsible wants to
> take over the job of deciding whether a release is "ready", I can certainly
> pull the trigger.

Ok That sounds good, I will try to make that roadmap, with what we feel is

> The bottleneck is not me per se; it's having qualified parties.  In the
> long run, having more tests would help a lot with that, as I've said before.
>  In the short run, it's people with strong multi-platform,
> multi-distribution, multi-project, multi-Python-version experience that are
> sorely lacking in the patch contribution, vetting, and design departments.

I think those people exists, but they are lacking of visibility in
setuptools projects, so they can't really contribute even if they would like
We don't really know where setuptools is going at this point,

I mean, there are mails like this one:

but a few up-to-date web pages would help a lot on this. I can try to work
on something besides the roadmap stuff, on the python wiki.
That's what we have started to initiate in our 'fork' in fact.

> And right now, the only way for me to evaluate such contributors is on the
> basis of their submitted patches and design proposals...  which are few and
> far between.  Historically, most of the patches I get are poorly thought-out
> even on the level of what the patch does for that one person; i.e., there
> will be cases that that very person will have problems with, let alone what
> problems other people will have.  This does not give me great hope for the
> viability of a fork whose expressed purpose is to accept more patches,
> faster.  :)

My "fork" is already starting to work if you think about it.

> (This situation is due largely to the flexibility of distutils, by the way.
>  The distutils accepts an utterly ridiculous number of possible source
> trees, for example.  It also supports a ridiculous number of installation
> targets, formats, etc.  On the other hand, this same flexibility also makes
> it virtually impossible for a competitor to "take over the market" unless it
> provides near-100% backward compatibility, as setuptools does.)

Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080925/185c84ff/attachment-0001.htm>

More information about the Distutils-SIG mailing list