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