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


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to