-----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 tsea...@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----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests