[Zope3-dev] Dealing with external dependencies

[Jim Fulton]

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

> 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 [1].

Yes.

> 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  
> are objections.

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.


> [1] 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  
> https://bugs.launchpad.net/grok/+bug/126742.

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

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org