New subject: Plugin Repo

25 Oct 2012 · *before*

      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.json file 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?
...
...

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 install first and get everything installed.
That would only work for people who have PHP 5.3 with composer and who have
shell access.
...
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.
...
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.
...
...

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

Re: [RCD] Plugin Repo