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/modulesto confirm to ZF's weird project structure:
https://github.com/easybib/EasyBib_Core_Composer_Zf1ModuleInstaller/blob/mas...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 somethingeither. 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 installbefore 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