I've begun working on the "salt" functionality in a branch of z3c.autoinclude:<br><br><a href="http://svn.zope.org/z3c.autoinclude/branches/adding-salt/">http://svn.zope.org/z3c.autoinclude/branches/adding-salt/</a><br>
<br>I think the functionality is essentially all there; I've got a few tests exercising it in a nontrivial way appended to README.txt though I haven't yet hand-tested it.<br><br>Before Martijn starts ripping into it [;)] -- I'll be the first to admit that the code is unpleasantly messy. There seem to be some significant refactoring opportunities to share code between include.py and plugin.py (I deliberately wrote the functions in plugin.py to use data structures similar to include.py's IncludeFinder) and there may be enough general-purpose code between the debugger, the TestDirective package's code, etc to merit some sort of 'utilities' module in there. In general I also found myself very unsure of where to actually put the new code. I wanted to call something "salt" (it's a really good name!) but I wasn't sure what, exactly. Before I went overboard cleaning it up, though, I wanted to let others know where I am so far and solicit any feedback.<br>
<br>The spelling differs a bit from Martijn's recommended "grokified" syntax. I preserved the `<includePlugins package="." />` directive, but the entry points look a bit different. Instead of<br>
<br>[z3c.plugin]<br>target = plone<br><br>it looks like<br><br>[z3c.autoinclude.plugin]<br>plone = myplugin.package<br><br>As I understand entry points, this is necessary, because an entry point does not contain any information about the package that provided it (so you need to spell it out explicitly somewhere) and because the right-hand side of the entry point is supposed to refer to an importable python object. There may be a better way to lay this out though. I wonder if using the "platform package" name in the section would be preferable, like<br>
<br>[z3c.autoinclude.plugin plone]<br>target = myplugin.package<br><br>Anyway, I'd welcome any and all feedback here.<br><br>Regards,<br>Ethan Jucovy<br><br><div class="gmail_quote">On Mon, Feb 25, 2008 at 10:22 AM, Martijn Faassen <<a href="mailto:faassen@startifact.com">faassen@startifact.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey,<br>
<br>
Martin Aspeli wrote:<br>
[snip]<br>
<div class="Ih2E3d">> plone.salt doesn't exist yet, though - Wichert has a prototype under a<br>
> different name, and I think others have played with this too (Whit,<br>
> maybe?). I'm wondering if it makes sense to have the "salt"<br>
> functionality as a part of the z3c.autoinclude package, since they are<br>
> reasonably similar and may benefit from sharing some code.<br>
<br>
</div>I think it would fit very well in z3c.autoinclude. I think the<br>
functionality fits well with the purpose of "auto inclusion", and as I<br>
already mentioned, there's a lot of infrastructure that you should be<br>
able to reuse.<br>
<br>
[snip]<br>
<div class="Ih2E3d">>> With z3c.autoinclude-like functionality you could make this smaller<br>
>> (note the name change :):<br>
>><br>
>> [z3c.plugin]<br>
>> target = plone<br>
><br>
> Does this functionality exist right nor, or are you saying we could<br>
> extend z3c.autoinclude to do this?<br>
<br>
</div>Not at all, it's just a proposal. :) What I meant is that I was basing<br>
the ideas on the experience we had designing and writing z3c.autoinclude.<br>
<div class="Ih2E3d"><br>
>> This would then dig up meta.zcml and configure.zcml from the current<br>
>> package. The only information necessary in the entry point is a<br>
>> specification of what it actually claims to plug into. You might want<br>
>> to consider making 'target' a dotted package name to actually give it<br>
>> namespacing.<br>
><br>
> Certainly looks nicer. ;-) I think having separate meta and configure<br>
> tags is probably unnecessary in the majority of cases.<br>
<br>
</div>I think that in by far the majority of the cases automatically loading<br>
both would be fine indeed.<br>
<br>
I think should someone want control, they should go the original way:<br>
include these things manually in an instance's site.zcml. How to allow<br>
this control?<br>
<br>
The only way I see is to have a way to here should be a way to turn<br>
*off* inclusion of a particular plugin. I think the ZCML exclude<br>
directive (which is available in an extension) could be used for this.<br>
This use case bears some thinking about as it's a problem we don't have<br>
for autoinclusion of dependencies. With plugins, the setup.py of the<br>
plugin is stating it wants to be included after all, and just the act of<br>
listing the package will make its ZCML be loaded by default.<br>
<div class="Ih2E3d"><br>
> It probably also makes sense to allow an optional syntax where different<br>
> *.zcml files are used as the starting point for different platforms. For<br>
> example, a package that has optional Plone support may have a plone.zcml<br>
> that's the starting point for Plone, a zope.zcml that's the starting<br>
> point for plain-Zope, etc.<br>
<br>
</div>Yes, this sounds useful. You might be able to get by with a convention<br>
that is driven by the directive though - i.e. the includePlugins<br>
directive can be instructed to load other things instead of the default<br>
configure.zcml and meta.zcml. This means that the package's setup.py do<br>
not need to list any of these things explicitly. I think that having<br>
such a convention makes for more easy to recognize structures in plugin<br>
than if you let people come up with their own mapping (plone:<br>
plone.zcml) in setup.py.<br>
<br>
For Grok we have the (not-yet-implemented) 'tagging' idea that serves a<br>
similar purpose - you mark particular components with tags using a<br>
directive so that they can be explicitly included or excluded.<br>
<div class="Ih2E3d"><br>
>> With a bit of cleverness you could then make the include statement<br>
>> shorter too (note my putting this into the 'zope' ZCML namespace and<br>
>> changing the name of the directive...):<br>
>><br>
>> <includePlugins target="plone" /><br>
><br>
> Cool. I'm not sure whether it's kosher to use the 'zope' namespace for<br>
> things that are not part of Zope 3, but this would of course be even nicer.<br>
<br>
</div>Yes, good point. We've done it with z3c.autoinclude already. "Part of<br>
Zope 3" is becoming a somewhat diffuse concept anyway. :)<br>
<div class="Ih2E3d"><br>
>> This sounds like nice functionality and we might cooperate on the<br>
>> implementation of such a package. z3c.autoinclude probably already<br>
>> includes much of what would be needed (including quite hairy test<br>
>> infrastructure), and it might make sense to simply extend that<br>
>> package's functionality with the new directive and entry point<br>
>> functionality.<br>
><br>
> That makes sense to me too. Are people (who? You? Uli?) happy for us<br>
> (who? me? wiggy? hannosch?) to do that (in a branch)?<br>
<br>
</div>Uli hasn't worked on this functionality yet. But I'd be happy to see<br>
this being done on a branch, and I'd be happy to discuss the technical<br>
details and review the changes too - just let me know when you need my<br>
help. I'm sure Ethan and Robert who worked with me on this during the<br>
snow sprint won't object either.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Martijn<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Grok-dev mailing list<br>
<a href="mailto:Grok-dev@zope.org">Grok-dev@zope.org</a><br>
<a href="http://mail.zope.org/mailman/listinfo/grok-dev" target="_blank">http://mail.zope.org/mailman/listinfo/grok-dev</a><br>
</div></div></blockquote></div><br>