[RCD] Plugin Repo

Thomas Bruederli thomas at roundcube.net
Thu Oct 25 20:07:28 CEST 2012


till wrote:
> On Thursday, October 25, 2012 at 7:21 PM, Thomas Bruederli wrote:
> [...]
>>>> * Then all the components are installed into the "vendor" directory and not
>>>> to plugins/. I already stitched together some scripts which hook into
>>>> composer's "post-package-install" and "post-package-uninstall" hooks and
>>>> then create or remove a symlink to the installed packaged within the
>>>> plugins directory of Roundcube. They could even add or remove the
>>>> particular entry to the plugins property in config/main.inc.php.
>>>  
>>> Another idea would be this:
>>>  
>>> We add a `"type": "roundcube-plugin"` and a custom installer to install somewhere else.
>>>  
>>> Then all the plugin authors need to do is set this type and require the plugin installer.
>>>  
>>> This wouldn't require post-install-cmd for every plugin — just a simple type.
>>  
>> Sounds good. What would it take to create such a customer installer? And
>> how would it be shipped?
> 
> Not a whole lot — did this before for ZF1 modules to be installed in `app/modules` to confirm to ZF's weird project structure:  
> https://github.com/easybib/EasyBib_Core_Composer_Zf1ModuleInstaller/blob/master/src/EasyBib/Core/Composer/Zf1ModuleInstaller.php  
> 
> I'll port this later.

Cool!
> 
> On shipping:
> 
>  * the installer is a composer package itself (roundcube/plugin-installer)
>  * plugins 'require' it so it's ensured it's installed first
>  * done

If we use the root composer.json to install plugins, I suppose it can also
be referenced there, right? Just to keep the requirements for a plugin's
composer.json file as low as possible.

> [...]
>>> Or you would download a complete release which includes all the dependencies.
>>  
>> I guess we still have to provide that for all the users who install
>> Roundcube through FTP on a shared hosting or whatever.
> 
> It's not like in this case they could use `pear install something` either. You can do it locally.
> 
> We can also see if we can figure out a frontend to pull in more plugins. But I haven't done this yet.  

That's planned for the future. Roundcube is supposed to get an admin panel
some day. And there's Rosali's plugin manager which already does something
similar but from his own repository. Maybe that can be tweaked to work
against our new composer repository, too,

>>> To create such a release, we would just `composer.phar install` before we zip/tar it up?
>>  
>> That's actually a good plan. However, it happens that Roundcube ships with
>> modified PEAR packages which are not yet publicly available. But I guess
>> for such cases we can put these modified libs into a separate repository
>> which is again referenced through the composer.json.dist file.
> 
> Correct. The code should be in forks.
> 
> Maybe a separate thread, but we should also try to get the code into upstream. Let me know if I can help.  

We usually file bugs and patches for PEAR packages and Alec meanwhile is
the maintainer of the Mail_mime package (our most important one). That way
we usually get fixes released very quickly.

~Thomas




More information about the dev mailing list