Am 07.02.2007 um 00:36 schrieb Martin Aspeli:
Why? Is it the ability to specify sensible version restrictions?
Have multiple versions of the same package as different
dependencies for different dependents? Automatic downloading of
dependencies where possible/desired? Standardised package metadata?
Standardised location to find and search for add-on libraries?
You mean the existing approach didn't support this? Ever heard of
sys.path? Sorry, I don't want to waste bandwidth on the CMF list on a
flame war. Eggs are there and I will have to learn to live with them
but I don't have to like them.
I know what's driving it and I know it's unfortunately almost
unavoidable but I don't have to like it. I've never had a problem
with using Products especially since the introduction of "local"
Products with Zope 2.7.
Meanwhile, the rest of the Python world came up with something
better and more widely accepted. Until Zope 2.10 and Plone 3, the
whole Plone and CMF stack depended on no library that was re-usable
outside of Zope (apart from PIL, and unless you count parts of Zope
3 shipped with Zope 2.8+). Eggs make your life easier, especially
if you want to use tools like workingenv.py or zc.buildout.
This is guff. Why should Zope add-ons *necessarily* be available as
third-party libraries? But if this is required it's no big deal to
put the Zope specific stuff in a Products folder and the library
in ../lib/python. Works fine for mxODBC
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests