Philipp von Weitershausen wrote at 2007-7-18 23:24 +0200:
>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
Which often is not so bad.
Many of my modules have been developped for ancient Zope versions
and kept running for several Zope releases -- even major ones.
Thus, unless I do not know whether a given package will *not* work
will a given future version of a dependancy,
I will not want to state the dependancy for the current version -- as
chances are high that it will indeed work with the next few
>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
>basically the equivalent of depending on a specific, well-known working
>version of the external package.
>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.
Don't you drastically increase the risk of conflicts?
As I understood in a different thread, you want to mix Zope eggs
with other eggs from the complete Python community. Such eggs may
have a dependency on the same "external" package than Zope --
and fixing the precise version by Zope can easily lead to conflicts.
Please keep dependency requirements weak -- restrict only when
you know it is necessary...
Zope3-dev mailing list