Hey,<br><br>I&#39;ve incorporated many of the recommendations in this thread into the adding-salt branch of z3c.autoinclude and cleaned up the code a bit.&nbsp; Three specific points follow, in increasing level of code detail.&nbsp; :)<br>
<br>First, in response to Martin&#39;s understandable confusion about autoinclusion (z3c.autoinclude&#39;s original functionality: dependency loading) vs plugin inclusion, I&#39;ve extracted a common base into z3c.autoinclude.utils and tried to distinguish more clearly between the two functions in the README.&nbsp; I also added a brief introductory section to the README which lays out how to use the package from a user&#39;s perspective (ZCML directives, entry points) without going into any of the details of the code or tests.&nbsp; I hope this makes it all a bit more clear.<br>
<br>On Sat, Mar 22, 2008 at 6:56 PM, Martijn Faassen &lt;<a href="mailto:faassen@startifact.com">faassen@startifact.com</a>&gt; wrote:<br>
&gt; We need to distinguish auto-inclusion from loading up plugins.<br>
&gt; Auto-inclusion means automatically also loading the ZCML of that<br>
&gt; dependency. <br><br>I think this terminology is contributing to the confusion.&nbsp; From a new user&#39;s perspective I think &quot;auto-inclusion&quot; 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 &lt;include&gt; statement.&nbsp; Perhaps we should disambiguate these and refer explicitly to &quot;including dependencies&quot; and &quot;including plugins&quot; throughout?&nbsp; (Rename include.py to dependency.py, IncludeFinder to DependencyFinder, etc.)&nbsp; Martijn, I&#39;m sure you have a strong opinion here -- how would you feel about renaming the ``&lt;autoinclude&gt;`` directive to something less ambiguous like ``&lt;includeDependencies&gt;``, symmetric to ``&lt;includePlugins&gt;``?&nbsp; (I&#39;d love to think of a shorter word than &quot;dependency&quot; for the directive but I&#39;m drawing a blank...)<br>
<br>Second, I&#39;ve changed the entry point syntax per Martijn&#39;s preference; it now looks like (using Products.CMFPlone as the example platform to plug in to) ::<br><br>&quot;&quot;&quot;<br>[z3c.autoinclude.plugin]<br>
target = Products.CMFPlone<br>&quot;&quot;&quot;<br><br>There is an implicit, enforced assumption that the right-hand side of the entry point (that is, the platform) is a valid dotted module name.<br><br>On Sat, Mar 22, 2008 at 7:32 PM, Martin Aspeli &lt;<a href="mailto:optilude@gmx.net">optilude@gmx.net</a>&gt; wrote:<br>
&gt; So long as we don&#39;t design the syntax or framework so that it&#39;s<br>&gt; 
impossible to cleanly support multiple targets in the future, I&#39;m happy<br>&gt; 
with that stance.<br><br>I&#39;m pretty sure that this syntax will work quite well for multiple targets (platforms) actually so you needn&#39;t worry.&nbsp; The left-hand side of the entry point (&quot;target&quot;) is completely extraneous so multiple entry points can be defined for a single plugin package already; I haven&#39;t written any tests to prove this but I think that something like the following would Just Work (assuming the &lt;includePlugins&gt; directives were specified somewhere, and assuming the package magically worked on two frameworks with the same configuration) ::<br>
<br>&quot;&quot;&quot;<br>
[z3c.autoinclude.plugin]<br>
target = Products.CMFPlone<br>smash = grok<br>
&quot;&quot;&quot;<br>
<br>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.&nbsp; But it seems we&#39;re all in agreement to leave this alone for now and wait for a real-world use case to (potentially) come up.<br>
<br>Anyway, that&#39;s about it for the update.&nbsp; If anyone&#39;s really interested in the inner workings, I refactored out a common base class ``DistributionManager`` which the ``IncludeFinder`` and ``PluginFinder`` both extend.&nbsp; There&#39;s some highly questionable makeshift adaptation of distribution objects and strings going on there which I&#39;m half-tempted to formalize with zope.component and zope.interface but that may be overkill, I&#39;m not really sure.&nbsp; As always, comments and criticism much appreciated.<br>
<br>Regards,<br>egj<br>