[Grok-dev] Re: Salt & z3c.autoinclude
optilude at gmx.net
Thu Mar 20 18:48:28 EDT 2008
Ethan Jucovy wrote:
> I've begun working on the "salt" functionality in a branch of
Awesome! Thanks so much for doing this!
> 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.
I must admit, I didn't understand the README.txt very well. Seems to me
like the first thing should be an up-front "here's how to use it"
section without all the test infrastructure. It's hard to tell from a
quick glance what's just there for testing and what's actually intended API.
I was expecting to see an entry point in the setup.py of various
packages in tests/ - is that not the case?
> 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
The branch name is good. ;-)
> 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
> target = plone
> it looks like
> 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.
[z3c.autoinclude.salt] # see what I did there? :-)
for:plone = myplugin.package
I don't think it overly matters, though.
What I don't quite understand is how the ZCML <autoinclude package="."
/> understands that it should go and get the things where target is
'plone' and not get all packages. I think it is easier conceptually to say:
<autoinclude platform="plone" />
Also, how do we handle meta.zcml? Do we need an autoinclude directive in
a package's own meta.zcml or can we get away with an ordering where all
meta.zcml files are done first (in which case we have to rely on the
name) and all others are done last.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev