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
job.
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
separate
weak-set egg that transaction and ZODB depend on and we'll need to decouple the
transaction exceptions from ZODB.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
