[Zope3-dev] Re: Dealing with external dependencies

[Tres Seaver]

-----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          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://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-----