[Zope3-dev] Re: Dealing with external dependencies
On 19 Jul 2007, at 00:43 , Jim Fulton wrote: 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. Now you tell us :). 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 guess. 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. Good point. 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. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? [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. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: 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. Good point. But not necessarily avoidable: if version 3 of library A depends on a feature provided by version 5 of library B, but version 7 of library C is incompatible with versions of library B 4, then those versions of A and C really *are* incompatible; that isn't an accidental clash. Library authors need to *minimize* their own depdendencies if they want to maximize their library's usefulness: that means avoiding depending on newer versions of libraries without *very( strong need (degrading gracefully, if possible). Another problem: the folks who manage your dependencies may not be very good at it: - They may remove old release versions, making it impossible to satisfy your dependency. - They may *replace* a release version (even more evil than removing it). - They may screw up SVN or CVS repository history (e.g., 'svn rename' will cause even a revision-specific external / checkout to break). 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. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). That situation is a fork, which may be the lesser of evils, depending on how things work out, especially in the face of poor upstream release hygeine. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? [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. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... System pythons be damned. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn6EQ+gerLs4ltQ4RAnJpAKCRI034pHc1a7MVLzblcS9Jegpn3QCfZgoW lE838s0c37QPT7GOuXTDM0M= =OW0w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
On Jul 19, 2007, at 1:09 PM, Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: 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. Now you tell us :). I just realized this over the weekend and even then wanted to discuss it with some folks. ... 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. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). Agreed. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? I hope so. :) [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. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... My objection isn't to install them as eggs, I'm a big fan of eggs, I'm just mystified by installing them as develop eggs. In any case, PJE tells me this is correct, so I need to deal with it. 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] Re: Dealing with external dependencies
On 19 Jul 2007, at 20:12 , Jim Fulton wrote: On Jul 19, 2007, at 1:09 PM, Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: 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. Now you tell us :). I just realized this over the weekend and even then wanted to discuss it with some folks. Fair enough. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? I hope so. :) Ok. Adam, those seem like clear instructions :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
