[RCD] Plugin Repo

till klimpong at gmail.com
Thu Oct 25 20:55:16 CEST 2012



On Thursday, October 25, 2012 at 8:07 PM, Thomas Bruederli wrote:

> 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.

We can — but in order to ensure it's installed *before* a plugin, the plugin itself must define it as a dependency.  
>  
> > [...]
> > > > 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,

I think technically the code is all available inside composer. Right now, the "cli" is just the primary interface.  
>  
> > > > 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.

OK, well let me know if there are issues no one attends to. I can use my QA karma to get it rectified. ;-)  

Till


More information about the dev mailing list