Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Log message for revision 97465: Branch removing zope.deferred.
This checkin is the branch I had in mind when sketching out a non-CPython-only zope.component story today. Notes on the changes: - - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE. - - Ripping out 'zope.deferredimport' required shifting to "from imports" to avoid cycles. I moved one other cycle down into a non-module-scope import, as well, using a 'global base' to avoid extra imports. - - All its tests pass in a buildout. - - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?) - - The branch can be installed into a virtualenv via 'setup.py develop', with only 'zope.interface' and 'zope.event' added. - - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too. - - It probably breaks something in the 'compattests' realm; I haven't tried that, yet. 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 iD8DBQFJra8y+gerLs4ltQ4RAnxvAJ9WijLQGtxOnqMX1XvNJFS4LWZ+PACfWhqJ KMrDhDwlA+kHYMOVuP34K6k= =K8ZI -----END PGP SIGNATURE-----
Tres Seaver wrote:
- - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE.
Why is zope.deferredimport a problem? Does it do something CPython specific? As a small utility, I don't think it's a particualrly troublesome dependency. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Tres Seaver wrote:
- - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE.
Why is zope.deferredimport a problem? Does it do something CPython specific? As a small utility, I don't think it's a particualrly troublesome dependency.
Have you looked at what zope.deferredimport actually does? It uses zope.proxy to create wrappers around objects in sys.modules! There is effectively no way that any Python developer who hasn't already drunk the Zope Koolaid will ever willingly put up with such a grotexque^Wingenious hack. The only way it can do that is via a C modlue (in zope.proxy), because CPython won't tolerate "duck typing" of module objects, which makes it a deal-killer for the non-CPython platforms, too. I thought originally that the dependency was there to support emitting deprecation warnings, but not so: essentially, the deferreed imports were there to paper over import cycles. Ripping it out meant making the inter-module dependencies *within* zope.component explicit and sane, which was a net win, too, even without losing the C extension. Note that I also had to switch to "from imports", because the other style is the actual source of the cycles (e.g., using the '@component.adapter' decorator at module scope). The transitive dependencies in the released zope.component (not counting testing dependencies) are: - zope.interface - zope.event - zope.deprecation - zope.deferredimport - zope.proxy On my branch, the transitive dependencies (again, not counting tests) are: - zope.interface - zope.event which feels a lot saner to me: zope.interface is obviously required for anybody using zope.component, and zope.event is tiny, unchanging, and pure Python (I *am* dubious of the real-world utility of the events it actually emits, but that is another story). I think that minimizing non-essential dependencies is crucial to getting wider use of the packages, especially outside the purple-lipped crew here in the compound. :) 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 iD8DBQFJrflv+gerLs4ltQ4RAnylAJ0f/uulXowSBdulTT0kO+bUzIXwWwCgoSyi a6M2GtcQN/qKag/bYammkmI= =iE1H -----END PGP SIGNATURE-----
2009/3/4 Tres Seaver <tseaver@palladion.com>:
- - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?)
- - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too.
What's the motivation behind removing test dependenices for functionality that actually requires these dependencies, like ZODB/hookable/etc.? -- WBR, Dan Korostelev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
- - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?)
- - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too.
What's the motivation behind removing test dependenices for functionality that actually requires these dependencies, like ZODB/hookable/etc.?
I was misled by the fact that ZODB isn't imported, except for testing:: [/home/tseaver/projects/Zope-CVS/zope.component-trunk] $ find src/ -name "*.py" | \ xargs grep -E "(from ZODB)|(import ZODB)" src/zope/component/tests.py: >>> import ZODB.tests.util src/zope/component/tests.py: >>> import ZODB.tests.util src/zope/component/tests.py: >>> import ZODB.tests.util The actual import is 'persistent': $ find src/ -name "*.py" | \ xargs grep -E "(from BTrees)|(import BTrees)" $ find src/ -name "*.py" | \ xargs grep -E "(from persistent)|(import persistent)" src/zope/component/tests.py:import persistent src/zope/component/persistentregistry.py:import persistent.mapping src/zope/component/persistentregistry.py:import persistent.list This seems to me like a good candidate for splitting out the persistent registry into a separate package. Right now, the 'extra' means that the package can be *installed* without the ZODB dependencies, but it can't be properly *tested* without them. 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 iD8DBQFJrpSv+gerLs4ltQ4RAhaVAJwNDdHUgb4zxO1hSCmo2NzeZH2rkgCbBSz9 2IJTlcwJxzfmsM3/dC+Of0Y= =ko+r -----END PGP SIGNATURE-----
Tres Seaver wrote:
Tres Seaver wrote:
Log message for revision 97465: Branch removing zope.deferred.
This checkin is the branch I had in mind when sketching out a non-CPython-only zope.component story today.
Wonderful, +1 I think the change makes sense from the perspective of zope.component as an individual package. Please keep those contributions coming :) Hanno
Hi there, I think all this makes sense, so +1 from me. Regards, Martijn
participants (5)
-
Dan Korostelev -
Hanno Schlichting -
Martijn Faassen -
Martin Aspeli -
Tres Seaver