[Grok-dev] Re: the projects in progress
faassen at startifact.com
Thu Feb 21 09:40:02 EST 2008
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
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.
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. 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
With z3c.autoinclude-like functionality you could make this smaller
(note the name change :):
target = plone
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
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" />
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.
Anyway, that's the Grok treatment of these plans. Much simpler now.
That's how we do things in these parts, partner. :)
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.
More information about the Grok-dev