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