[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
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
More information about the Python-Dev