Re: Breaking up PEAK
Phillip J. Eby <pje@...
2005-06-14 12:25:29 GMT
At 09:30 AM 6/6/2005 -0400, Erik Rose wrote:
>I'd worry less about trying to normalize the structure of PEAK as if it
>were a DB and more about the interaction with users' brains. I think
>the breakdown you suggested3 clumps of about 5 packages eachis good;
>it fits ESR's definition of compactness
>and each clump even fits in the
>5-plus-or-minus-2 size of human working memory. If you break things
>down further, I think new users will again descend into panic, saying
>"I have no idea what this thing does; there are 500 pieces!"
That's just it, though; if things can stand on their own, they can stand on
their own. For example, there is an assortment of testing utilities in
peak.util: mockdb, mockets, and unittrace. The odds that anybody will do
much of anything with them in peak.util is pretty much nil, but if I
bundled them as a mini-project (perhaps called "MockTesting"), it'd
probably get some interest from TDD-oriented folks.
Similarly, nobody's going to install PEAK just to get peak.util.uuid and
friends, but as a "PyUUID" package that provides a cross-platform API for
the draft UUID/GUID spec, and that's another thing people would download.
Neither MockTesting nor PyUUID would have the same audience as the rest of
PEAK, and there's absolutely no connotation that you have to learn these
packages in order to "learn PEAK".
There are many other use-case oriented groupings of PEAK's contents that
could be spun off to live as semi-independent packages. The purpose here
isn't to "normalize" PEAK, but rather to make its functionality accessible
to a wider audience (in the overall sense) by having individual packages be