Based on what I see at http://plugins.roundcube.net/, and my experience with Composer, it seems like all plugins should have their own repository, and should be installed either with Composer or they can be handled via git submodules.
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 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.
Quite happy to write/implement this myself, so long as the idea/direction is acceptable to the lead RC devs.
Thoughts?
On Apr 20, 2013, at 1:35 AM, rodrigo rodrigo@corp.sonic.net wrote:
Based on what I see at http://plugins.roundcube.net/, and my experience with Composer, it seems like all plugins should have their own repository, and should be installed either with Composer or they can be handled via git submodules.
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 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.
Quite happy to write/implement this myself, so long as the idea/direction is acceptable to the lead RC devs.
The plugins website is still being set up, so what you're seeing isnt live yet. Hopefully soon, and by then im sure we'll get an announcement regarding the use of composer for plugins. Some plugins, including mine, already have the necessary composer.json files, so should be easy to move them to the new plugins site.
Cor
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.
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 (http://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.
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. :)
Till
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
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.
Arguably it would actually be nice if the core plugins would also move to composer. Then you can easily do a composer update and grab updates of core plugins as well.
I am doing a lot with a php framework called Laravel lately, and I really like their philosophy regarding composer. If you're going to use composer, REALLY use composer. Next step, move all of roundcube to composer and split out core modules into composer modules. Also, maybe re-use other third-party composer packages in roundcube. For this end, roundcube should become PSR-0 compatible :)
Cor
On Saturday, April 20, 2013 at 1:56 PM, Cor Bosman wrote:
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.
Arguably it would actually be nice if the core plugins would also move to composer. Then you can easily do a composer update and grab updates of core plugins as well.
I am doing a lot with a php framework called Laravel lately, and I really like their philosophy regarding composer. If you're going to use composer, REALLY use composer. Next step, move all of roundcube to composer and split out core modules into composer modules. Also, maybe re-use other third-party composer packages in roundcube. For this end, roundcube should become PSR-0 compatible :)
I agree that all of this would be nice. And I'll +1 each of these.
One of the "downsides" of composer is that it requires PHP 5.3. Last time we had a discussion on upping the requirement, a lot of people were against it. That's one of the issues. Maybe it's time to have that discussion again though and with 1.0 we could move there?
The other is that composer's code is currently "optimized" to run on the cli. I have a small WIP plugin installer which is a RoundCube plugin itself, but it requires a lot of ram for a single run. This doesn't look like a bug to me, it's just that composer builds the entire dependency tree before it evaluates what it can install etc. — and this requires a lot of processing power. I am also sure that there are things that could be profiled and improved but so far no one had the requirement yet.
On the CLI — this is usually not an issue, but in a web context this is more of an issue because it requires upping the memory_limit, max_execution_time, etc..
http://plugins.roundcube.net/packages/till/plugin_manager
Till
On Saturday, April 20, 2013 at 1:49 PM, Thomas Bruederli wrote:
On Sat, Apr 20, 2013 at 2:17 AM, till <klimpong@gmail.com (mailto: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.
The plugins were in their own tree in SVN. Maybe that's what I meant.
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 (http://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 _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
till wrote:
On Saturday, April 20, 2013 at 1:49 PM, Thomas Bruederli wrote:
On Sat, Apr 20, 2013 at 2:17 AM, till <klimpong@gmail.com mailto: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.
The plugins were in their own tree in SVN. Maybe that's what I meant.
Yes, they were back in the SVN times. But even there, it was one repository holding all plugins not individual repositories for each plugin.
But I don't say that moving the core plugins to composer is a bad idea. So far my intention of the plugin repository didn't consider that step but it might.
~Thomas
On Saturday, April 20, 2013 at 2:14 PM, Thomas Bruederli wrote:
till wrote:
On Saturday, April 20, 2013 at 1:49 PM, Thomas Bruederli wrote:
On Sat, Apr 20, 2013 at 2:17 AM, till <klimpong@gmail.com (mailto:klimpong@gmail.com) mailto: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.
The plugins were in their own tree in SVN. Maybe that's what I meant.
Yes, they were back in the SVN times. But even there, it was one repository holding all plugins not individual repositories for each plugin.
But I don't say that moving the core plugins to composer is a bad idea. So far my intention of the plugin repository didn't consider that step but it might.
I think the only downside is:
- More repositories.
- Running RoundCube from src would require an
./composer.phar install - Build system/releases would need to be updated as well.
We could include all our vendors as dependencies via composer. Might not be the worst thing and it would cause less noise in the git tree when updates need to be performed?
Till
-
Cor Bosman -
rodrigo -
Thomas Bruederli -
Thomas Bruederli -
till