[Grok-dev] Re: the projects in progress

[Martijn Faassen]

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).

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:

  [plone.salt]
  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 :):

  [z3c.plugin]
  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 
namespacing.

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.

Regards,

Martijn