[Zope-CMF] Re: Tools as local utilities

[Martin Aspeli]

Charlie Clark wrote:
> 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?

Sure, I mean, that's all they do, manage sys.path for you. But it's way 
easier to be more declarative about your dependencies and their 
versions, and having automatic downloads of dependencies (even indirect 
ones) can save a lot of time and make it easier to try things out.

> 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'm not quite sure it's wasted bandwidth in the sense that I believe 
moving to distribution using eggs could benefit CMF and its dependents 
greatly. This pressure is coming from both sides: Zope (3) and Plone. 
I'm pretty sure the Silva guys are fairly enthusiastic about eggs, too.

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

Managing lib/python manually is quite painful. For example, we have a 
lot of things we want to keep in the plone.* namespace. These are 
developed by different people. When people had to symlink things in 
(before we got eggs) or we were building bundles, merging multiple 
packagings of libraries into lib/python/plone/ and lib/python/plone/app 
became difficult, time-consuming and really, really hard to explain to 
newbies.

Mostly, I'm basing this on empirical evidence, though. In the latter 
part of the Plone 3 development cycle, we started pushing eggs pretty 
hard. We got familiar with tools like paster, setuptools and 
easy_install which help make this fairly painless. Before Plone 3, we 
made no use of external, non-Zope specific libraries (apart from PIL); 
to be honest, we hardly even looked for them, because of the 
distribution headache (Plone at that point was a tarball for Products/). 
Now, we've got half a dozen or so packages that other people (primarily 
Zope 3 people for now, but as Zope 3 becomes eggified as well it gets 
easier to re-use things outside Zope entirely) can use (grok is playing 
with our AJAX infrastructure, for example). We also know that we can 
find, try and ultimately declare dependencies for packages quite easily.

I don't think eggs/setuptools are perfect. But I don't think they're 
useless either, and on the whole, so far, they've brought more benefits 
than problems. By playing with eggs, we're playing better with the rest 
of the Python community (and things like entry points are very cool). We 
start being able to re-use some of their tools (workingenv, buildout, 
paster) and participate more meaningfully by sharing code.

In any case, I don't mean this to be acrimonious in any way. I'm justing 
saying that depending on a non-Products package (be it egg-distributed 
or not) shouldn't be a problem (because there will only be more and more 
of these).

Martin