[ZODB-Dev] RE: lost "implementer"

[Tim Peters]

[Jim Fulton]
> 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.

Still, even if they're not, it's up to the PYTHONPATH whether Zope or ZODB's
zope.interface "wins".  That's been an occasional problem with Zope2 on
Windows too, where some users fight at times to get their own version of a
standard Python module used instead of Zope2's bundled version.

>     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.

That would be nice :-).

> 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. :)

I don't know enough about "eggs" specifically, but "a real packaging system"
is the key.  At the moment, we've reinvented a form of "DLL Hell" on
Windows:  the last thing you install overwrites all shared components.
Since we're not yet sharing all that much, it can't sanely be called "hell"
yet, but that is what it says on the sign at the end of the road ;-)

Paying attention to versions is a good way to get off that road.