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 _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
