[Grok-dev] Re: Salt & z3c.autoinclude

Martijn Faassen faassen at startifact.com
Tue Mar 25 08:06:34 EDT 2008

Hey Ethan,

Ethan Jucovy wrote:
> On Sat, Mar 22, 2008 at 6:56 PM, Martijn Faassen <faassen at startifact.com 
> <mailto:faassen at startifact.com>> wrote:
>  > We need to distinguish auto-inclusion from loading up plugins.
>  > Auto-inclusion means automatically also loading the ZCML of that
>  > dependency.
> I think this terminology is contributing to the confusion.  From a new 
> user's perspective I think "auto-inclusion" would seem to describe both 
> functions of the package: whether it is loading ZCML from dependencies 
> or plugins, the package is performing the same task of automatically 
> including packages without any explicit per-package <include> 
> statement.  Perhaps we should disambiguate these and refer explicitly to 
> "including dependencies" and "including plugins" throughout? 

You're right, I will use 'including dependencies' instead of just 
'auto-inclusion' from now on.

> (Rename 
> include.py to dependency.py, IncludeFinder to DependencyFinder, etc.)  
> Martijn, I'm sure you have a strong opinion here -- how would you feel 
> about renaming the ``<autoinclude>`` directive to something less 
> ambiguous like ``<includeDependencies>``, symmetric to 
> ``<includePlugins>``?  (I'd love to think of a shorter word than 
> "dependency" for the directive but I'm drawing a blank...)

+1. There's still time to change the Grok trunk/grokproject too once the 
new z3c.autoinclude is released. I think the longer directive name is 
fine; people aren't going to type it a lot anyway.

> More importantly though, the fact that the left-hand side is ignored 
> entirely leaves plenty of room for a future syntax extension there which 
> specifies a ZCML starting point, which would make the above example 
> rather more useful.  But it seems we're all in agreement to leave this 
> alone for now and wait for a real-world use case to (potentially) come up.

Thanks for the analysis here, and +1 to wait until a real-world use case 
comes up.

> Anyway, that's about it for the update.  If anyone's really interested 
> in the inner workings, I refactored out a common base class 
> ``DistributionManager`` which the ``IncludeFinder`` and ``PluginFinder`` 
> both extend.  There's some highly questionable makeshift adaptation of 
> distribution objects and strings going on there which I'm half-tempted 
> to formalize with zope.component and zope.interface but that may be 
> overkill, I'm not really sure.

As long as it stays inside the package and has no pluggability concerns, 
makeshift is fine for now, I think.

I'll try to give it a code review soon; please give me a reminder if you 
don't hear anything!

Thanks very much for this excellent work, Ethan!



More information about the Grok-dev mailing list