[Grok-dev] Re: the projects in progress

[Martijn Faassen]

Hey,

Martin Aspeli wrote:
[snip]
> 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.

I think it would fit very well in z3c.autoinclude. I think the 
functionality fits well with the purpose of "auto inclusion", and as I 
already mentioned, there's a lot of infrastructure that you should be 
able to reuse.

[snip]
>> 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?

Not at all, it's just a proposal. :) What I meant is that I was basing 
the ideas on the experience we had designing and writing z3c.autoinclude.

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

I think that in by far the majority of the cases automatically loading 
both would be fine indeed.

I think should someone want control, they should go the original way: 
include these things manually in an instance's site.zcml. How to allow 
this control?

The only way I see is to have a way to here should be a way to turn 
*off* inclusion of a particular plugin. I think the ZCML exclude 
directive (which is available in an extension) could be used for this.
This use case bears some thinking about as it's a problem we don't have 
for autoinclusion of dependencies. With plugins, the setup.py of the 
plugin is stating it wants to be included after all, and just the act of 
listing the package will make its ZCML be loaded by default.

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

Yes, this sounds useful. You might be able to get by with a convention 
that is driven by the directive though - i.e. the includePlugins 
directive can be instructed to load other things instead of the default 
configure.zcml and meta.zcml. This means that the package's setup.py do 
not need to list any of these things explicitly. I think that having 
such a convention makes for more easy to recognize structures in plugin 
than if you let people come up with their own mapping (plone: 
plone.zcml) in setup.py.

For Grok we have the (not-yet-implemented) 'tagging' idea that serves a 
similar purpose - you mark particular components with tags using a 
directive so that they can be explicitly included or excluded.

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

Yes, good point. We've done it with z3c.autoinclude already. "Part of 
Zope 3" is becoming a somewhat diffuse concept anyway. :)

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

Uli hasn't worked on this functionality yet. But I'd be happy to see 
this being done on a branch, and I'd be happy to discuss the technical 
details and review the changes too - just let me know when you need my 
help. I'm sure Ethan and Robert who worked with me on this during the 
snow sprint won't object either.

Regards,

Martijn