[Grok-dev] Re: the projects in progress

Martin Aspeli optilude at gmx.net
Thu Feb 21 11:13:13 EST 2008


Martijn Faassen wrote:
> Martin Aspeli wrote:
> [snip]
>>> I'm going to test this code in my own project. We can also investigate 
>>> whether Grok can use it itself for its own dependencies, which should 
>>> make Grok's maintenance a bit easier.
>> Please also see my note about "Salt". No-one's replied to that one yet, 
>> but I think there's a lot of room for collaboration there.
> 
> Yes, I read your note about Salt, thanks for that. For Grok, I'm not 
> sure whether something like Salt will be as immediately useful as for 
> Plone. Grok has never used slugs, we just include ZCML of dependencies 
> directly in our configure.zcml (and this is now automated away with 
> z3c.autoinclude).

Yep - I agree. I just want to make sure we don't duplicate any effort if 
there are places when it does overlap.

> As far as I understand it, Salt is intended to easily plug in extensions 
> into Plone that needs ZCML. If a package wants to be a Plone plugin, it 
> can register itself with an entry point, and then its ZCML will be 
> automatically included by Plone.

It's not Plone-specific, but yeah, that's the idea.

> I think this makes sense for a pluggable application, in the particular 
> scenario that the person who *deploys* Plone wants to make the decision 
> to use a certain plugin or not. It makes less sense for someone who 
> wants to *develop* on top of Plone and wants to make use of 
> functionality provided by an extension. 

Yep, I agree. Although I think people will perhaps get into the habit of 
depending on plone.salt loading the ZCML for their dependencies. To that 
end, I would like to encourage people to use *both* the "salt" approach 
to register any pluggable components they want to "just work" with Plone 
(or other things) *and* use z3c.autoinclude to ensure that their 
dependencies are indeed loaded.

plone.salt doesn't exist yet, though - Wichert has a prototype under a 
different name, and I think others have played with this too (Whit, 
maybe?). I'm wondering if it makes sense to have the "salt" 
functionality as a part of the z3c.autoinclude package, since they are 
reasonably similar and may benefit from sharing some code.

> In that case I'd develop a new 
> Python package that depends on whatever Plone extensions it needs in its 
> setup.py. z3c.autoinclude could then make sure the ZCML is loaded.
> 
> For a typical Grok application, the latter scenario is more common: 
> people would develop their own Python package and just list any 
> dependencies it needs in setup.py. If you want to ship an application 
> and some plugins, write a new project that depends on the application 
> and the plugins both.
> 
> Of course if larger Grok applications grow up, the pluggable application 
> scenario may become more relevant. It'd be nice to have something.

Agree.

> So let's give Salt the grok treatment. You currently spell it like this:
> 
>   [plone.salt]
>   configure:plone[>=3.0,<4dev] = my.package:configure.zcml
>   meta:plone = my.package:meta.zcml

Well, that's just a syntax I dreamt up while writing the proposal. I'd 
like for it to be conceptually consistent with z3c.autoinclude and other 
similar things.

> With z3c.autoinclude-like functionality you could make this smaller 
> (note the name change :):
> 
>   [z3c.plugin]
>   target = plone

Does this functionality exist right nor, or are you saying we could 
extend z3c.autoinclude to do this?

> This would then dig up meta.zcml and configure.zcml from the current 
> package. The only information necessary in the entry point is a 
> specification of what it actually claims to plug into. You might want to 
> consider making 'target' a dotted package name to actually give it 
> namespacing.

Certainly looks nicer. ;-) I think having separate meta and configure 
tags is probably unnecessary in the majority of cases.

It probably also makes sense to allow an optional syntax where different 
*.zcml files are used as the starting point for different platforms. For 
example, a package that has optional Plone support may have a plone.zcml 
that's the starting point for Plone, a zope.zcml that's the starting 
point for plain-Zope, etc.

> With a bit of cleverness you could then make the include statement 
> shorter too (note my putting this into the 'zope' ZCML namespace and 
> changing the name of the directive...):
> 
> <includePlugins target="plone" />

Cool. I'm not sure whether it's kosher to use the 'zope' namespace for 
things that are not part of Zope 3, but this would of course be even nicer.

> If you'd use the package dotted name for the target functionality as I 
> mentioned above, this can be shorter still:
> 
> <includePlugins package="." />

Nice. ;-)

> This includes all plugins registered for the current package. Should you 
>   want to include the plugins registered for another package, you could 
> indicate that using 'package=' too.
> 
> I don't know why Salt needs to know about version information. Wouldn't 
> your buildout only include packages with appropriate versions? Buildout 
> *and* setup.py can take care of locking down versions, and now here Salt 
> goes along and does the same thing? What's the motivation for that? You 
> could pick up ZCML for only a particular version, but it seems to make 
> no sense to do this - if the required version of the plugin is not 
> appropriate, you'd magically get no plugin registered (that is, none of 
> its ZCML executed, other things might happen?), which sounds just plain 
> confusing instead of helpful.

Yeah - maybe you're right that this is redundant. The package probably 
break way before it ever got to the ZCML loading stage if it was 
installed for the wrong version of Plone/whatever.

> Anyway, that's the Grok treatment of these plans. Much simpler now. 
> That's how we do things in these parts, partner. :)

Hehe. I like it.

> This sounds like nice functionality and we might cooperate on the 
> implementation of such a package. z3c.autoinclude probably already 
> includes much of what would be needed (including quite hairy test 
> infrastructure), and it might make sense to simply extend that package's 
> functionality with the new directive and entry point functionality.

That makes sense to me too. Are people (who? You? Uli?) happy for us 
(who? me? wiggy? hannosch?) to do that (in a branch)?

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Grok-dev mailing list