[Zope-CMF] Re: Tools as local utilities
optilude at gmx.net
Tue Feb 6 19:41:25 EST 2007
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
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
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
More information about the Zope-CMF