[Distutils] Annoucing distribute project

[Phillip J. Eby]

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.


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

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.

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.  :)

(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.)