On Sat, Apr 20, 2013 at 2:17 AM, till klimpong@gmail.com wrote:
On Saturday, April 20, 2013 at 1:35 AM, rodrigo wrote:
Is there any particular reason the default set of included (but not activated) plugins has not been separated out from the main repository into repositories of their own? I would even argue that skins, aside from the default, should be separate repositories. My group manages our installation with git and it would make my life a ton easier if this were the case.
I don't remember when they were put back into the "master". They used to be more separate.
Wrong. Plugins developed and maintained by the Roundcube developers always have been part of the master git repository together with the code code. The planned composer-based plugin repository is meant for 3rd party plugins. The main goal of that repository is to allow plugin developers to publish their modules on a centralized platform and allow Roundcube sysadmins to pull them into their local installations. That isn't necessary for core plugins because they're already part of the distribution package.
We can easily spin them off with a git subtree split — also keeping the history, etc.. But yeah, in its current state composer requires individual repositories and so on. I guess this is more or less of question of handling these externals.
I saw an answer to "[RCD] update.sh clobbering custom plugin configs in main.inc.php?" earlier today, suggesting that a config file within the plugin should be edited. Plugins are basically vendor code, wouldn't it make more sense to make a plugin_name.inc.php within /config, and have a plugin standard (in the form of a config grabber method) that grabs the appropriate config file? This way, the plugin could be updated by composer or git, and there'd be no worry about overwriting configs, or editing vendor code. It'd encourage plugin writers to keep their config separate from the roundcube config, because there'd be an easily accessible function for it.
We already have that separation but not in the centralized /config directory but in the individual plugin folders. And this basically should survive an update via composer.
I'd also like that. I think up until now the configuration part hasn't seem too much love and is very legacy. But if you have ideas, feel free to bounce them around. :)
There's a general refactoring of the config system planned: http://trac.roundcube.net/ticket/1487311 Please add your inputs and comments there.
~Thomas