I agree that the plugin directory is getting a little burdensome, particularly since this means answering more and more questions each time a new one is added regarding the necessary requirements and dependencies. Therefore, I agree that they should be moved out of the regular installation process.<br>
<br>The plugins/ directory might be the right place for that. The other alternative would be to pull them off into separate packages completely. This would make them separate entities on CPAN and affords all the pros (better author credit, a separate release schedule, separate support options) and cons (not available with the central distribution, yet another CPAN module to install, releases that get out of sync) that implies. We could also do a little of both.<br>
<br>In any case, I think CLK is right: we need some general policy about what plugins are core (lib/Jifty/Plugin, share/plugin), what plugins are included with the Jifty distribution but are installed separately (plugins/), and what plugins should be distributed separately altogether. I&#39;ve been placing my plugins in core or included since that&#39;s what I was encouraged to do from the start, but I&#39;d certainly distribute them separately if it would be helpful.<br>
<br>Cheers,<br>Sterling<br><br><div><span class="gmail_quote">On 3/11/08, <b class="gmail_sendername">Chia-liang Kao</b> &lt;<a href="mailto:clkao@bestpractical.com">clkao@bestpractical.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br> <br> with the increasing numbers of jifty plugins being committed to the<br> repository, I think it&#39;s a good idea to come up with some guidelines for<br> maintaining plugins, and more importantly, keep the core jifty modules slim.<br>
 <br> right now, lots of modules (33) are added directly under<br> lib/Jifty/Plugin and share/plugins/.&nbsp;&nbsp;This approach makes it a lot<br> easier to test and deploy, but also creates problems like messy optional<br> dependencies.&nbsp;&nbsp;there are a few other modules under plugins/, which are<br>
 harder to install (and takes extra effort to test against the in-tree<br> jifty).<br> <br> I think the plugins/ approach is probably more correct, as it makes it<br> possible to release them separately and list plugin-specific<br>
 dependencies.&nbsp;&nbsp;But to make it as easy as putthing all things under lib<br> to test and install, we need:<br> <br> - in toplevel Makefile.PL, takes an argument listing all plugin<br> directories we want to test and install<br>
 - make the toplevel makefile.pl call the plugins&#39; makefile.pl with<br> proper predefined harness_perl_switches to include the lib in jifty tree.<br> - optionally a shortcut arg in makefile.pl to include core modules, all<br>
 modules under plugins/.<br> - make the &quot;test&quot; and &quot;install&quot; targets call the same targets for plugins.<br> <br> What do people think?<br> <br> Cheers,<br> CLK<br> <br> _______________________________________________<br>
 jifty-devel mailing list<br> <a href="mailto:jifty-devel@lists.jifty.org">jifty-devel@lists.jifty.org</a><br> <a href="http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel">http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel</a><br>
 </blockquote></div><br>