Re: [Zope3-dev] Dealing with external dependencies
On 19 Jul 2007, at 19:36 , Dieter Maurer wrote: ... 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? Yes, probably. I've been convinced now that making libraries depend on specific versions isn't such a good idea. Thanks for the input. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dealing with external dependencies
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dealing with external dependencies
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:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Dealing with external dependencies
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. 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. [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. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
