-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Lange wrote:
I'm trying to update my application to use the recent patch that Tres Seaver helpfully landed on zope.app.testing.
The new zope.app.testing seems to require a new zope.component, since it's importing hooks from z.component rather than zope.site.
However, when I update zope.component, I get the following error from zope.app.component:
Traceback (most recent call last): ... File ".../zope.app.component-3.8.3-py2.5.egg/zope/app/component/metaconfigure.py", line 15, in <module> from zope.component.zcml import PublicPermission, _checker, view, resource ImportError: cannot import name PublicPermission
It appears that r83 of lp:zope.component moves PublicPermission from zope.component.zcml to zope.component.security.
The latest releases of zope.app.component are basically pure backward compatibility shims at this point.
Now, my app is only using metaconfigure in this instance to get at PublicPermission and view, so I might as well import them from zope.component directly, solving my immediate problem.
However, this still leaves zope.app.component broken with new zope.component releases.
The zope.app packages often to be updated in synch with new "major" releases of their dependencies: they have often had their "reusable" bits factored out into new or existing packages, for instance.
I can't find the code for zope.app.component on Launchpad,
Development is done in the zope.org subversion repository. I don't think we have a mirror yet on LP: http://svn.zope.org/zope.app.component/ Code is released to PyPI: http://pypi.python.org/pypi/zope.app.component/ The changelog outlines the information you are interested in: http://pypi.python.org/pypi/zope.app.component#changes Moving version of the code from 3.6.0 and after requires looking carefully at the changelog, and tracking compatible versions of the dependencies.
but the fix seems pretty simple – import PublicPermission from z.component.security.
It seems to me that zope.component is also broken, since moving PublicPermission to a new module breaks backwards compatibility. I've attached a patch that goes some way to fixing this.
More generally, I'm a bit worried that this attempt of mine to upgrade the zope.testing that my app uses is going to result in a cascade of dependency upgrades, each with their own little backwards compatibility problems. What sort of expectations should I have? e.g. Do the version numbers tell me anything about intended compatibility?
The overall problem of keeping multiple, layered packages in useful configurations is our "known good set" (KGS) problem. http://download.zope.org/zope3.4/intro.html The last releaes of the appserver-formerly-known-as-Zope3 was based on version 3.4 of the KGS, released 2009-01-20. We then retired the name "Zope3" and began working on the set of libraries from it under the moniker "Zope Toolkit" (ZTK), with the intent of stripping it down to the "reusable" bits from Z3, in a configuration which could be shared by Zope2, Grok, and existing Z3 apps (now BlueBream): http://docs.zope.org/zopetoolkit/ (see especially "Migration Issues") The three platforms are close to converging on a 1.0 version of the ZTK: http://docs.zope.org/zopetoolkit/releases/packages-trunk.html which is in machine-readable form (designed for use with zc.buildout) here: http://svn.zope.org/zopetoolkit/trunk/ztk.cfg?rev=110721&view=auto with the 'zope.app.*' packages broken out into a dependent layer: http://svn.zope.org/zopetoolkit/trunk/zopeapp.cfg?rev=110721&view=auto On the whole, we have done a reasonably good job of maintaining backward compatibility across minor releases of software: we have decided in some cases to break it deliberately when moving to new major versions (e.g., to shed certain dependencies entirely), but may have fallen behind on documenting the changes required to migrate application code to those versions. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvDiLEACgkQ+gerLs4ltQ72CgCgni+OXT7uwCXrpSvUomSh9lEH XOcAnR4LNc68orIjzv83ZFBHkIgdmRDh =bcJO -----END PGP SIGNATURE-----