[Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns

Phillip J. Eby pje at telecommunity.com
Wed Mar 19 16:21:00 CET 2008

At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
>Are you open to giving certain others patch view/commit privileges 
>to setuptools?

Jim Fulton has such already.  I'm open to extending that to others 
who have a good grasp of the subtleties involved.

Truthfully, if we can just get 0.6 put to bed, I could probably open 
up the trunk a lot wider.

One of the things that slows me down is that patches usually don't 
come with tests, so I usually have to manually smoke-test them for 
scenarios I think they'll effect.  There isn't really any automated procedure.

Probably the most frustrating thing (or "chief amongst the most 
frustrating things") about setuptools development is that it's a 
black hole.  By which I mean that backward compatibility and cruft 
accretion make it difficult to get out of.

In the beginning, there was the distutils.  Distutils begat 
setuptools, and setuptools begat virtualenv and zc.buildout and 
source control plugins.  Etc., etc.

What I think is really needed in the long run is to keep eggs, but 
get rid of setuptools and the distutils in their current 
form.  There's a lot of brokenness there, and also a lot of 
accumulated cruft.  We really need a distutils 3000, and it needs to 
be built on a better approach.

In truth, my *real* motivation for PEP 365's bootstrap tool isn't so 
much to support the package management tools we have today, as it is 
to support a new one tomorrow.  I have a few ideas for ways to shift 
the paradigm of how individual projects get built, to incorporate 
many scenarios that don't work well now.  But to implement those 
things in such a next-generation tool, I will not want to be 
restricted to just what's in the stdlib or what can be bundled in the tool.

(Btw, by "real" motivation, I don't mean I've been deceptive about my 
intentions, I mean that my strong intuition that such a bootstrap 
facility is needed, is probably being fueled by the long term desire 
to replace the entire distutils-based infrastructure with something better.)

>   I'd be willing to help out, and keep a carefully balanced hand in 
> what is accepted.

And I think it's probably getting close to time I stepped down from 
day-to-day management of the codebase (which is more like 
month-to-month or quarter-to-quarter for me lately).  It will 
probably be a lot easier for me to step back and critique stuff that 
goes in, after the fact, than to go over the stuff beforehand.  :)

I'm not sure exactly how to go about such a handoff though.  My guess 
is that we need a bug/patch tracker, and a few people to review, 
test, and apply.  Maybe a transitional period during which I just say 
yea or nay and let others do the test and apply, before opening it up 
entirely.  That way, we can perhaps solidify a few principles that 
I'd like to have stay in place.  (Like no arbitrary post-install code hooks.)

btw, offtopic question: are you by any chance the same Jeff Rush who 
invented EchoMail?

More information about the Python-Dev mailing list