Tim Peters wrote:
That's my fault, and I apologize for the inconvenience.  Alas, I'm not sure
it won't happen again -- while sharing packages across projects has many
attractions, it also creates that many more opportunities for "related"
projects to get out of synch wrt the package versions they include, and it
would take real effort to coordinate which package versions all related
projects include.  While there's nothing wrong with "real effort", the
_kind_ of real effort needed is akin to teaching a family of cats spread
across the globe to dance in unison with each other ;-)

I have 2 answers. :)

1. This points out the benefit of not treating Zope as a library.
   Zope releases contain specific configurations of packages known
   to work together.  It should have control over that configuration
   and it can't do that if everything is slammed into one global place.

   We decided for Zope 3 to leverage distutils to make the Windows
   installer. We thought we'd try the distutils "way" of installing
   things into site-packages.  IMO, it was worth trying.  Now we know
   that it really isn't the right approach, despite the fact that it
   provided some benefits.

   I still *want* to leverage distutils, or at least some technology
   that is broadly adopted by the Python community.

2. I think a real packaging system, like eggs would have helped here.
   Eggs in particular would have allowed multiple versions of zope.interface
   to be installed.  Zope would have gotten the version it needed and ZODB
   would have gotten the version it needed. (Hm, maybe eggs *would* make
   treating Zope as a library work. :)


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:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to