[PEAK] Beginning the breakup

[Phillip J. Eby]

I've managed to get setuptools to a good enough place to allow automatic 
dependency installation in a sane way, so I'm starting to plan the first 
breakups of the PEAK ouevre.  I was originally going to convert our CVS 
repository to subversion before doing any breakups, but I've found through 
attempts at converting it, that cvs2svn doesn't like the repository 
symlinks we're using to share stuff between projects.

That's a bit of a problem, since we share a *lot* of stuff between 
projects.  So it looks like we'd probably be better off eliminating the 
sharing *before* even considering moving anything to subversion.

I think the first step is going to be to get rid of PEAK's embedded 
versions of setuptools, by migrating to the current Python CVS sandbox 
version that I've been developing on.  This will be accomplished by adding 
the 'ez_setup.py' script to each of the projects (PEAK, PyProtocols, 
wsgiref) that uses it.  After that, I'll delete the source of setuptools 
from the CVS HEAD as a normal revisioned delete.  The only tricky bit about 
that is that there will be a period between some of the commits where an 
intermediate checkout wouldn't work correctly due to conflicts between 
ez_setup and setuptools.  But at the end everything should be fine and the 
history intact.

The next thing that's shared across a bunch of products is the 
src/setup/common.py file.  However, I only use the stuff that's in it to 
generate online documentation, and documentation for the "source+doc" 
distribution variants.  Does anybody use it for anything else?  I'm 
actually leaning towards getting rid of the "source+doc" distribution 
format anyway, in favor of just generating and distributing the 
documentation separately.  But I'm open to feedback on all this.  Anyway, 
my current thought is just to nix src/setup/common.py and update my 
server-side scripts to run happydoc directly for the online docs.

After these two, the first big split will occur: the 'dispatch' package 
will get its own project distribution, tentatively called "RuleDispatch", 
with a version of something like 0.5a1.  In order to do this, I'm going to 
have to actually *copy* the subtree in CVS, so I can keep the history sane 
in both PyProtocols and the new RuleDispatch project.  Once I've copied it, 
I'll of course delete it from the PEAK+PyProtocols HEAD.  RuleDispatch will 
require a 1.0a version of PyProtocols, but PyProtocols won't depend on 
anything but setuptools.  PEAK will depend on RuleDispatch.

The next split would then be to copy wsgiref, protocols, and fcgiapp to 
their respective projects from PEAK (instead of continuing to share them 
via symlinks), and then delete them from PEAK's HEAD, adding the requisite 
dependencies.  I'd also delete ZConfig, and add some optional dependency 
settings to indicate which PEAK tools need ZConfig installed.

At that point, it should be pretty easy to get a full install of PEAK using 
EasyInstall or just setup.py install.  For development purposes, it's going 
to be harder to work on something that involves simultaneous changes to 
multiple projects, but it's not that often that I do that anyway.  In fact, 
the current situation sometimes causes me to forget to do an update to 
download into PEAK something I changed in PyProtocols.  So, it'll probably 
work out just fine to keep things separate.

After these initial splits, I can start looking at others, but for right 
now I'm thinking that RuleDispatch, PyProtocols, PEAK, wsgiref, and fcgiapp 
are plenty for us to be distributing at the outset.  I think I'll also need 
to set up some sort of "daily build" cronjobs for all the projects so that 
it's easy to use EasyInstall to get development versions of stuff, and 
development versions can rely on a particular datestamp.

Anyway, this is all just a bunch of random musings on how it'll all 
work.  Any thoughts, input, or questions are appreciated.