[Grok-dev] Salt & z3c.autoinclude

[Ethan Jucovy]

I've begun working on the "salt" functionality in a branch of
z3c.autoinclude:

http://svn.zope.org/z3c.autoinclude/branches/adding-salt/

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.

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.

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

[z3c.plugin]
target = plone

it looks like

[z3c.autoinclude.plugin]
plone = myplugin.package

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

[z3c.autoinclude.plugin plone]
target = myplugin.package

Anyway, I'd welcome any and all feedback here.

Regards,
Ethan Jucovy

On Mon, Feb 25, 2008 at 10:22 AM, Martijn Faassen <faassen at startifact.com>
wrote:

> 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
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080320/9e5cc6bb/attachment-0001.htm