Chris McDonough wrote:
I'm taking a stab at packaging the various pieces of ZODB as eggs. One of the things I'd like to do is to separate the packages of ZODB that are currently shipped together (BTrees, ZODB/ZEO, persistent transaction, ZConfig) into separate packages, because each may arguably be useful outside of what we call "ZODB" now.

One of the issues I've run into is that there are compile-time dependencies between packages mainly due to C header files. For example, the BTrees package assumes that it will be able to find the cPersistence.h file, which currently ships with the "persistent" package. I wonder if I should bother breaking the persistent and BTrees packages apart as separate eggs. I suspect not.

I realize BTrees aren't terribly useful outside of persistent storage, so reasonable response would be to say "don't split pieces of ZODB up into separate subpackages unless they don't share much/any code". In that case, I might create a "persistence" egg that includes both the 'persistent' and 'BTrees' packages. The "ZODB" egg might include both ZODB and ZEO (these are linked inextricably) which depends on the "persistence" distribution. Transaction should be dependency-free (but probably isn't, I haven't gotten that far yet).

So in any case, for ZODB, if I punted on the "one-package-one-egg" relationship, we'd wind up with (for example):

persistence-3.6.0.egg (which would include persistent and BTrees  modules).
zodblib-3.6.0.egg (which would include ZODB and ZODB packages).
transaction-3.6.0.egg (which would include only the transaction  package).
zconfig-2.3.1.egg (which would include only the ZConfig package).
zodb-3.6.0.egg (which might be an empty "dependency" package that depended on persistence, transaction, zodblib, and zconfig).

Anyone care?

Yup.  However, I think before we can package these separately, we need to
fix the dependency graph. in particilar we have a lot of cycles, which is
bad.  For example. ZODB depends on ZEO. persistent and transaction depend on
ZODB.  I think that this needs to be cleaned up first.  This is not a small

BTW, the turbogears folks are interested in using transaction.  The transaction
package has shallow dependencies on ZODB.  A nice start would be to release
a separate transaction egg that doesn't depend on ZODB.  (Hint, we'll need a 
weak-set egg that transaction and ZODB depend on and we'll need to decouple the
transaction exceptions from ZODB.)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to