[Grok-dev] Re: the projects in progress
optilude at gmx.net
Thu Feb 21 11:13:13 EST 2008
Martijn Faassen wrote:
> Martin Aspeli wrote:
>>> 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
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.
> So let's give Salt the grok treatment. You currently spell it like this:
> 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
> With z3c.autoinclude-like functionality you could make this smaller
> (note the name change :):
> 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
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="." />
> 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)?
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