On Jul 18, 2007, at 5:24 PM, Philipp von Weitershausen wrote:
Up until now we've been a bit sloppy when it came to egg
dependencies. Not specifying a version number or range basically
means that the code in question assumes it will work with any
future version of its dependency. Admittedly, setuptools doesn't
exactly make it easy to say "I depend on ZODB 3.8.x". Jim has
proposed to add a syntax to setuptools to support this nicely but
it's not there yet. So I guess we'll have to wait for that.
Heads up: I've come to think that depending on major revisions/series
isn't going to work. I'll say more about that in a separate thread
Things are a bit different with external dependencies (docutils,
mechanize, ClientForm, twisted, etc.), I think. They bear a higher
risk of breaking stuff for us in future releases, even if they're
just minor releases, because we don't control them and their
developers probably don't test their stuff with our code .
Back in the old days, we would do vendor imports or use revision
tags for the externals.
This was at the monolithic zope checkout level.
This was basically the equivalent of depending on a specific, well-
known working version of the external package.
I'm not sure what you mean here. The equivalent to what we did
before is to depend on specific versions at the *application* level,
by fixing a version in a application meta package or in a buildout.
I propose to do the same for the external dependencies we have. So
far I only count docutils as an actual egg dependency because
mechanize, ClientForm and twisted are still packaged up in the egg
that uses them (we should change that, too). I will therefore
change zope.app.renderer to depend on docutils==0.4, unless there
Depending on specific versions in library packages (as opposed to
application packages or buildouts) is a recipe for disaster IMO. As
soon as 2 packages depend on different externals, then those 2
packages won't be usable together.
In the long run, it might be better to only reuse packages that offer
some backward compatibility promises. Depending on a specific version
will make the dependent packages less reusable.
 This problem has bitten us over at Grok because apparently
Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to
actually exist anywhere and therefore confuses zc.buildout. See
I'm fairly sure that this has nothing to do with version numbers. I
suspect instead that it has something to do with the fact that all
distributions are now installed as "develop eggs" on ubuntu. The
locations of these eggs is actually site-packages. This sounds very
wonky to me, but Phillip Eby says it is normal. I'd be interested in
following up on this offline or in a separate thread.
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list