[PEAK] Beginning the breakup
Phillip J. Eby
pje at telecommunity.com
Tue Jun 28 01:03:18 EDT 2005
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.
More information about the PEAK
mailing list