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