Re: [Zope-dev] [dev] five.localsitemanager: dependencies
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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?
Only for someone wishing to use it totally outside of a Zope context.
Given that package's job in life, I strongly doubt that we need to worry about anybody using it outside of a Zope2 app. In fact, I think it might be a good idea just to fold the package back into Zope2 (I don't recall why it ever shipped separately).
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. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJlxyD+gerLs4ltQ4RAnMhAKCVNpXav5TpO17EQDJKPeIE/JLC1wCfVzWY maFcuCWJJY09WMDwxsYz4G4= =wJCe -----END PGP SIGNATURE-----
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. Hanno
-----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@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-----
[...] five.localsitemanger [...] Tres Seaver wrote:
Given that package's job in life, I strongly doubt that we need to worry about anybody using it outside of a Zope2 app. In fact, I think it might be a good idea just to fold the package back into Zope2 (I don't recall why it ever shipped separately).
IIRC someone (probably Rocky) needed local site managers in a project and started the code. We maintained and expanded it over time. Looking at the actual dependencies of the package today and the way it needs to override some of the things inside OFS, I think merging it into Zope2 makes sense at this point. So for this particular package I'm +1. In general I'd like there to be less "Five code" to be part of Zope2 though. Moving formlib support into a five.formlib package might be worthwhile for example. Right now Zope2 pulls in quite a bit of packages through zope.formlib and zope.app.form which next to nobody is working on anymore. I'd like to avoid Zope2 getting maintenance cost for packages just because we offer a Five-layer for them inside Zope2. Since five.localsitemanager is really just depending on the hardcore component architecture itself, I'm fine with including this one, though. Hanno
participants (3)
-
Hanno Schlichting -
Tres Seaver -
yuppie