[Zope-dev] zope.app.component broken with zope.component 3.8.0 and greater?

[Tres Seaver]

-----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 at 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-----