[Zope-dev] [dev] five.localsitemanager: dependencies

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hanno Schlichting wrote:
> Tres Seaver wrote:
>> Charlie Clark wrote:
>>> Am 12.02.2009 um 14:45 schrieb yuppie:
>>>>       install_requires=[
>>>>         'setuptools',
>>>>         'Zope2 >= 2.12.dev',
>>>>       ],
>>>>
>>>> Is that the right way to resolve that issue? Could it cause any  
>>>> trouble
>>>> if I would check in that change?
>>> I'm not that familiar with Buildout but I would have thought that any  
>>> direct import dependencies should be listed - and zope.location  
>>> doesn't seem to be (neither are zope.event or zope.site for that  
>>> matter). OTOH the condition >= seems to be being incorrectly  
>>> interpreted. If this is a bug then it should be filed.
>> The transitive dependencies of another dependency don't need to be
>> listed:  the problem Yuppie was fixing was a set of over-specific
>> dependencies, now redundant in the new, egg-centric world of Zope 2.12.
>> I think another fix would be to move the Zope2 import to the top of the
>> list, so that its own, more specific dependencies would be installed
>> first:  however, I don't see much win over Yuppie's fix.
> 
> My main reason for specifying all direct dependencies of any package
> (and not just the Zope2 one) is that relying on transitive dependencies
> can cause trouble later on.
> 
> For example:
> 
> Package A depends on Zope2 (2.12)
> Package A depends on zope.app.foobar
> Zope2 2.12 depends on zope.app.foobar
> 
> You could specify that package A only depends on Zope2.
> 
> But what if Zope2 2.13 does no longer depend on zope.app.foobar?
> 
> Suddenly you try to install Package A and import statements for
> zope.app.foobar break.
> 
> With zope.app.foobar it is probably easier to see how such a package
> could be removed later on (say it has been renamed to zope.foobar or
> split into multiple packages) but it really can happen to any package.
> 
> In a package based world, if you specify a dependency on a package, you
> can in my opinion only rely on the package contents itself to be there.
> You cannot rely on its dependencies to stay around.
> 
> Zope2 the package is no different in this. Chances are that
> zope.location will stay a dependency of Zope2 for a long time, but for
> other packages it is far less clear. My answer to this is to always
> specify all direct dependencies.

The point in Yuppies changes is that the already-specified dependencies
*broke anyeay* with Zope 2.12, because of details of ordering inside
setuptools.  Specifing *any* version requirements (even '>=x.y') is
impossibly fragile outside the context of a tightly-controlled index (at
which point the version requirements are redundant, and should be removed).

As I said earlier:  five.localsitemanager should just be made part of
the Zope2 trunk:  it is tightly-coupled to Zope2, and its presence as a
separate pacakge is just confusing and error-prone.



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

iD8DBQFJmDoS+gerLs4ltQ4RAlkVAJ0c14H5duToioqUYi6CCoM0PTeGewCgjzJH
YlJg6uNLQeqfPxuN4hYleGw=
=PcWY
-----END PGP SIGNATURE-----