--
till
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday, October 25, 2012 at 7:21 PM, Thomas Bruederli wrote:
I'm taking this to the dev list again since the conversation became more general and interesting for all.
till wrote:
On Thursday, October 25, 2012 at 6:59 PM, Thomas Bruederli wrote:
till wrote:
On Thursday, October 25, 2012 at 11:00 AM, Thomas Bruederli wrote:
Cor Bosman wrote:
One thing that i find a little disappointing about this packagist/composer combo is that it really just is a bookmark list. Users have to actually move to github or google to fetch the plugin.
That's true but on the other hand it encourages people to publish their stuff on github which clearly has it's advantages.
Hey guys – there is a major confusion! ;-)
What you do is this:
Use the
composer.jsonfile in roundcubemail (currently available in master only), and add this to repositories:"repositories": [{ "type": "composer", "url": "http://plugins.roundcube.net/" }]
Then it require — something like
"cor/message_highlighter"
./composer.phar install — and it's installed.
I was now playing around with the composer scripts and tried to figure out a proper way how Roundcube plugins can actually be installed using composer. Here are some issue I came across:
- one has to add the plugins wished to be installed to the required section
of the composer.json file from the local Roundcube installation. That means one has to alter a file which is actually distributed with Roundcube. A possible solution could be to ship Roundcube with a file named composer.json.dist which one has to copy to a local copy named composer.json which can then be managed through composer.
The .dist is a good idea.
- 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/mas...
I'll port this later.
On shipping:
- the installer is a composer package itself (roundcube/plugin-installer)
- plugins 'require' it so it's ensured it's installed first
- done
- The required PEAR packages are also installed into "vendor" while they're
actually shipped with Roundcube itself. I suggest to remove them entirely from the composer.json file and only handle plugins there.
I would rather not check them into GIT anymore.
If you run from a git clone, you would
./composer.phar installfirst and get everything installed.That would only work for people who have PHP 5.3 with composer and who have shell access.
If you run round cube from a git-clone, you don't have these things? :-)
Besides, you can also do this:
- git clone …
- cd roundcubemail
- ./composer.phar install
And then FTP it up.
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.
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.
- If plugins require further components or libraries though their
composer.json file, they'll also be installed into the local vendor directory but Roundcube might fail to load them. Therefore the Roundcube core would have to use the autoloading scripts installed by composer. That's something I still have to implement and test.
if (file_exists("vendor/autoload.php")) { require "vendor/autoload.php"; }
That's what I had in mind, yes.
The goal was to first evaluate whether composer would be a good base for Roundcube's plugin repository. While it seems to be OK for publishing plugins, their installation seems to be a bit tricky and limited to systems running PHP 5.3 because of composer's requirements and heavy use of namespaces.
Just to make sure: Namespaces are not required in plugins. Only composer itself needs 5.3. But it can install PHP 5.2 code as well.
In all honesty — PHP 5.3 has been out for forever. 5.2 EOL'd 2 years ago: http://www.php.net/archive/2010.php#id2010-12-16-1
Even Debian has 5.3 nowadays. ;-))
But yeah — this would come with the requirement for 5.3. But I don't think this will be a huge issue, unless we make it one.
I guess we had that conversation recently in the list and some people still objected against dropping PHP 5.2 support.
I never said RoundCube itself would have to drop it.
But for the plugin installer, it's just a requirement. Plugins can also leverage PHP 5.3 features — just add the PHP version in "require".
Till