March 2009 - Zope-Dev

Dependencies for ZCML
by Dan Korostelev 18 Mar '09

18 Mar '09

2009/3/11 Martijn Faassen <faassen(a)startifact.com>: >> Oh, and on the topic, one more time: can we have a steering group >> decision on the package requirements for zcml statements? Are we doing >> extras for them or simply skipping them? > > Sorry, I wasn't clear that there was an open question and I'm afraid I > don't understand this one. :) > > Could you point me to the appropriate thread that was left in the > middle, or could you start a new thread with a description of the open > question? I'm too lazy now to search in archives, so I'll just describe again. For example, the zope.password package only requires zope.interface to be functional. But it's configure.zcml contains directives that need zope.component (or repoze.zcml) and zope.security. Also, the zcml thing itself needs zope.configure as well. Should we mention it in extra dependencies somehow or just document it, saying that zcml is intented to be used in more zope3-ish environment that already has needed packages, so others can simply ignore these files. -- WBR, Dan Korostelev

9 21

Re: [Zope-dev] Dependencies for ZCML
by Tim Hoffman 17 Mar '09

17 Mar '09

Hi I would like to chime in here on the zcml I have managed to get a core stack of zope3 running on gae had to hack a lot of zope.security and zope.proxy to get it there, but it all works quite well I found I had to ignore zope.configuration to get most of the base stack working because the default configure.zcml in most packages introduced a lot of dependancies that weren't always necessary at least for me. In most cases I manually and selectively setup a whole lot of provideAdapter setups to get a minimal working set, Later I found I went back to get a minimal zope.configuration going, becuase it became way to much effort to register all of the base z3c.form components (widgets, dataconverters and terms) that I wanted registered. How is this relevant to to discussion, I found reading the unit tests didn't really enlighten me how many of the packages should be registered in the broader framework and had to rely on the zcml to work it out, however the zcml often pulled in dependancies that where not obvious from other packages because the various registrations and order of registrations that are performed in a normal zope deployment. This means the zcml is pretty important description of how the components are used in the broader context, it also means I think tests that are dependant on the zcml registration working is important, however the downside is the zcml does usually bring in things like browser views, which you may not want and so need to then gut some of the zml. Just my 2c worth T P.S. Sorry about the top posting, I though I was subscribed to the list, but wasn't so didn't have the original posting to reply to

2 1

Zope Tests: 6 OK
by Zope Tests Summarizer 17 Mar '09

17 Mar '09

Summary of messages to the zope-tests list. Period Mon Mar 16 12:00:00 2009 UTC to Tue Mar 17 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 16 21:24:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011283.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 16 21:26:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011284.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 16 21:28:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011285.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 16 21:30:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011286.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 16 21:32:11 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011287.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 16 21:34:13 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011288.html

1 0

zopectl does not terminate
by Hedley Roos 17 Mar '09

17 Mar '09

Hi all I run my script foo.zctl with "zopectl run foo.ctl param1 param2". This script operates on a large ZODB and catches ConflictErrors accordingly. It iterates over a set, updates data and commits the transaction every 100 iterations. But I've noticed two things: 1. ConflictErrors are never fully caught. The show up in the console (this is acceptable I suppose), but my script stops executing on the conflict and does not continue. The zope process stays alive. 2. In the event of no conflict errors my script executes its last line (print 'done') but the process does not always terminate. If I instruct my script to not update the ZODB at all it terminates without problems. I'm running it on a live site with 7 ZEO clients. I've stopped a client (say client 2) so it is not accessed concurrently and run my script with client2/zopectl. It is in fact a Plone site but that should be irrelevant. Thanks for any help Hedley

2 1

Categorizing Packages: Clarifying Terms
by Tres Seaver 16 Mar '09

16 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A blog entry trying to clarify terminology, offered in the interest of "light vs. heat": http://www.palladion.com/home/tseaver/obzervationz/2009/package_categories_… Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)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 iD8DBQFJvtuh+gerLs4ltQ4RAq1pAKCplCpGBtwupcQjuLpU+bTnynjLTACgpv3k 74sQBUGbC0TP3WSuHlbD8O4= =1kD8 -----END PGP SIGNATURE-----

1 0

zope:view directive
by Dan Korostelev 16 Mar '09

16 Mar '09

2009/3/16 Michael Howitz <mh(a)gocept.com>: > zope.container has a similar problem: its configure.zcml uses zope:view > directives. When I'd like to use zope.container in a Zope 3 the application > server environment I have to know that zope:view is defined in > zope.app..component or I have to find it out. There is no dependency, not > test and no documentation mentioning this inside zope.container. BTW, what's zope:view was created for? Shouldn't we just move from zope:view to simple zope:adapter and deprecate zope:view to get rid of confusion? -- WBR, Dan Korostelev

1 0

Re: [Zope-dev] [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
by Michael Howitz 16 Mar '09

16 Mar '09

Am 15.03.2009 um 23:47 schrieb Roger Ineichen: > Hi Michael > > Can you explain why you implemented the login viewlets? The login in zope.app.security is implemented using browser pages and metal-macros and is not really customizable. I needed a login/logout which works fine with pagelets and behaves like the one in zope.app.security as I think zope.app.security was not implemented so badly. > What does this viewlets have to do with the pagelet layer? It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. > I think they are very project specific and should go to > an explicit package which offers login viewlets. I'm not sure about this, as the implementation as adopted from the one in zope.app.security. I don't think the one in zope.app.security is project specific. But I might be wrong. > The pagelet layer has nothing to do with such explicit > implementations. The z3c.layer.pagelet package offers > only the minimum setup for make pagelets traversable > and offers error handling etc. My implementation does not even require new dependencies. ``zope.authentication`` and ``zope.principalregistry`` where split out from zope.app.security to reduce dependencies. > What do you think, can we move your viewlet part into > another package which is based on z3c.layer.pagelet > or probably on z3c.layer.ready2go which uses the pagelet > layer too? It could be an idea to add it to z3c.layer.ready2go which currently only contains some interfaces. But a completely new package seems a bit overkill to me. Yours sincerely, -- Michael Howitz · mh(a)gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development

3 3

Dependencies on zope.app.appsetup
by Dan Korostelev 16 Mar '09

16 Mar '09

Hi there. One of most annoying dependencies is the "zope.app.appsetup" package. Some packages, like zope.session depend on it just to provide "boostrap setup" for using these packages in context of "zope3, the application server", however, they can be greatly used without it, so this is really awful dependency. I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/ The problem is that the bootstrap code in zope.app.appsetup is really "zope3, the application"-specific, so it uses "root folders", persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the "zope3 application server", but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers). So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an "extra" dependency (sigh...). Ideas? -- WBR, Dan Korostelev

4 3

zope.app.security refactoring results
by Dan Korostelev 16 Mar '09

16 Mar '09

Hey there! The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: * zope.authentication - the most interesting and small. It contains the IAuthentication contract, as well as IUnauthenticatedPrincipal/IAuthenticatedGroup and company. Beyond that, it also contains several utilities related to principal lookup - the PrincipalLookupError and PrincipalSource/PrincipalTerms. * zope.principalregistry - it's an implementation of IAuthentication that's based on global non-persistent registry object. It provides zcml-based principal creation. Yes, it's the "global principal registry" from zope.app.security. * zope.localpermission - the implementation of persistent/local permission class that can be added and used per-site. It's a bit of (possibly deprecated) TTW development. I created another thread about possibility of death of local permisions, so may be this package will be named "zope.app.localpermission" and forgotten forever. :) Also, two other packages were touched: * zope.security - here migrated some bits of zope.app.security - the NoProxy definition for zope.i18nmessageid.Messages, the permission vocabularies, zcml definitions of some common permissions, like zope.View. * zope.publisher - here migrated the adapter from IPrincipal to ILoggingInfo and the adapters from zope.publisher's HTTP/FTP requests to ILoginPassword. May be they will be moved again, when we'll be doing zope.publisher's refactorings. One nice feature provided as a result of refactoring is possiblity of the authentication system to be used without of zope.publisher. The zope.app.authentication and z3c.authenticator probably can be modified/refactored not to depend on zope.publisher as well, but it will be another task. The original zope.app.security now only contains browser views and BBB imports. Other packages still need to be adapted to new imports, but I'd like to do that after releasing refactored packages. I already adapted zope.securitypolicy and zope.app.authentication though. It's a big win for zope.securitypolicy that it doesn't pull the whole zope anymore. Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) -- WBR, Dan Korostelev

3 5

Standard request/response API
by Jim Fulton 16 Mar '09

16 Mar '09

There's been some discussion recently about separating the interfaces in zope.publisher from the implementations to facilitate other implementations. I think it would be great to standardize request and response APIs. I'd love to see this extend beyond the Zope community. I believe that there have been some moves to try to do this at the WSGI level, although I haven't kept up with the discussion. Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. This might be an excellent project for PyCon. Jim -- Jim Fulton Zope Corporation

6 8