[Zope-CMF] Re: Tools as local utilities
charlie at begeistert.org
Tue Feb 6 19:06:12 EST 2007
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
More information about the Zope-CMF