-----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 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-----
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
