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