Re: [Zope-dev] Dependencies of zope.error
Hey, Thomas Lotze wrote: [snip] I think I'll release the current zope.error later today so people get the benefit of the lighter dependencies. Given you access to this too. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies of zope.error
Martijn Faassen wrote: Thomas Lotze wrote: I think I'll release the current zope.error later today so people get the benefit of the lighter dependencies. Given you access to this too. :) Thank you, I've just made the release. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies of zope.error
Tres Seaver wrote: - zope.error depends on zope.container solely in order for the error reporting utility to be able to subclass Contained, which in turn calls itself a silly mix-in class. Also, zope.error makes no use of the fact that the utility is Contained. Should the Contained support be dropped or somehow made conditional on whether zope.container is available? +1 for dropping Contained. +0 for making it conditional. I've dropped the dependency on the Contained mix-in class but not the fact of the utility being contained: it now implements zope.location.interfaces.ILocation directly. This means I've dropped the package dependency on zope.container but kept one on zope.location. +sys.maxint to using a mock request object, and dropping the dependency. Done. I think I'll release the current zope.error later today so people get the benefit of the lighter dependencies. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Dependencies of zope.error
- The last release of zope.error doesn't have all dependencies declared while work has been done on the trunk to fix that. Is there a specific reason why no new release has been made since? - zope.error depends on zope.container solely in order for the error reporting utility to be able to subclass Contained, which in turn calls itself a silly mix-in class. Also, zope.error makes no use of the fact that the utility is Contained. Should the Contained support be dropped or somehow made conditional on whether zope.container is available? - zope.error depends on zope.publisher which is only used by the tests in order to provide a request object from which to read some information for the error log. However, the code that reads that information is rather liberal as to what the request actually is, and doesn't technically require it to be a zope.publisher HTTP request. I think this should be made more consistent by either making the error logging code stricter or using a minimal request object in the tests. Opinions? Cutting the dependency on zope.container would drop the total number of dependencies of zope.error (trunk) from 30 to 22, additionally cutting the dependency on zope.publisher would make it 10. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies of zope.error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Lotze wrote: - The last release of zope.error doesn't have all dependencies declared while work has been done on the trunk to fix that. Is there a specific reason why no new release has been made since? Likely somebody thought there was remaining work to be done. - zope.error depends on zope.container solely in order for the error reporting utility to be able to subclass Contained, which in turn calls itself a silly mix-in class. Also, zope.error makes no use of the fact that the utility is Contained. Should the Contained support be dropped or somehow made conditional on whether zope.container is available? +1 for dropping Contained. +0 for making it conditional. - zope.error depends on zope.publisher which is only used by the tests in order to provide a request object from which to read some information for the error log. However, the code that reads that information is rather liberal as to what the request actually is, and doesn't technically require it to be a zope.publisher HTTP request. I think this should be made more consistent by either making the error logging code stricter or using a minimal request object in the tests. Opinions? +sys.maxint to using a mock request object, and dropping the dependency. Cutting the dependency on zope.container would drop the total number of dependencies of zope.error (trunk) from 30 to 22, additionally cutting the dependency on zope.publisher would make it 10. Good start. :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKu5vQ+gerLs4ltQ4RAn5CAKDIjWV6uvab7OovMLhT5PyWFpiqjQCfexGA l3OgzZSLpYK76z66+wC+edw= =qHFX -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
