[Zope-CMF] Re: Tools as local utilities

[Charlie Clark]

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

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226