[Zope3-dev] Dealing with external dependencies
Dieter Maurer
dieter at handshake.de
Thu Jul 19 13:36:09 EDT 2007
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
>dependency.
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
future versions.
> ...
>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]. 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...
--
Dieter
More information about the Zope3-dev
mailing list