Hello folks
Sadly, our attempts to set up a central repository for plugin failed so far. Till once started with the idea to install a PEAR channel and to use PEAR-style package descriptions to define dependencies but that project stuck a while ago.
I'd like to ask again for volunteers to help us creating a plugin repository for Roundcube. There's a new star shining on the PHP packaging sky named Composer [1] and I was wondering if some of you already made some experiences with it. It seems like a light-weighted and easy-to-use system to define packages and dependencies including version checks.
And there's the Packagist project [2] which exactly does what I have in mind as a plugin repository and which could be forked to tweaked for our needs.
So if anybody is willing to create a prototype repository which could serve the Roundcube plugins, you'd make us and the entire community very happy.
Any feedback in Composer vs. PEAR or general suggestions for the plugin repository are welcome!
Best, Thomas
hi Thomas, are you saying to store plugins inside packagist.org? Or to take the packagist.org code and set up a roundcube version?
Cor
Cor Bosman wrote:
hi Thomas, are you saying to store plugins inside packagist.org? Or to take the packagist.org code and set up a roundcube version?
I was thinking of setting up our own packagist instance to build the repository. But first we should figure out whether the composer approach would be suitable.
~Thomas
Personally I really like the Wordpress way of dealing with plugins. (http://wordpress.org/extend/plugins/about/)
Not too formalised (because a lot of plugins are not well maintained), and an admin interface inside wordpress to see what plugins are new and can be updated automatically.
Cor
On 10/22/2012 12:04 PM, Thomas Bruederli wrote:
I was thinking of setting up our own packagist instance to build the repository. But first we should figure out whether the composer approach would be suitable.
IMHO the composer + own packagist.org installation is quiet a good idea. I'll see if I find time to bundle RC with composer. The only problem I see with this change is, that composer requires namespaces -> PHP 5.3 The RC requirement at the moment is PHP5.2.1. Note: The PHP 5.2 release has been marked as end of support since nearly 2 years. http://www.php.net/archive/2010.php#id2010-12-16-1
Dominic
On Monday, October 22, 2012 at 2:05 PM, Dominic Lüchinger wrote:
On 10/22/2012 12:04 PM, Thomas Bruederli wrote:
I was thinking of setting up our own packagist instance to build the repository. But first we should figure out whether the composer approach would be suitable.
IMHO the composer + own packagist.org (http://packagist.org) installation is quiet a good idea.
I'll see if I find time to bundle RC with composer. The only problem I see with this change is, that composer requires
namespaces -> PHP 5.3 The RC requirement at the moment is PHP5.2.1. Note: The PHP 5.2 release has been marked as end of support since nearly 2
years. http://www.php.net/archive/2010.php#id2010-12-16-1
Hey Dominic,
composer doesn't require PHP 5.3 namespaces.
foo_blah works just as nice. I'm using both "at work".
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
Till
Dominic _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
Hey Dominic,
composer doesn't require PHP 5.3 namespaces.
foo_blah works just as nice. I'm using both "at work".
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
One thing im wondering about composer/packagist. Is there an API through which RC or a plugin can offer a plugin admin page inside roundcube. If not, I think that is a serious negative.
Cor
On Monday, October 22, 2012 at 2:20 PM, Cor Bosman wrote:
Hey Dominic,
composer doesn't require PHP 5.3 namespaces.
foo_blah works just as nice. I'm using both "at work".
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
One thing im wondering about composer/packagist. Is there an API through which RC or a plugin can offer a plugin admin page inside roundcube. If not, I think that is a serious negative.
Whatever the plugin wants to do does not depend on the "installer"?
Or can you explain how the installer would need to be aware of it?
Till
On Oct 22, 2012, at 2:31 PM, till klimpong@gmail.com wrote:
On Monday, October 22, 2012 at 2:20 PM, Cor Bosman wrote:
Hey Dominic,
composer doesn't require PHP 5.3 namespaces.
foo_blah works just as nice. I'm using both "at work".
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
One thing im wondering about composer/packagist. Is there an API through which RC or a plugin can offer a plugin admin page inside roundcube. If not, I think that is a serious negative.
Whatever the plugin wants to do does not depend on the "installer"?
Or can you explain how the installer would need to be aware of it?
What I mean is, that if a roundcube installation admin logs into RC, they can see all plugins that are installed (similar to about page), but also see if new versions are available, and maybe even update right from roundcube. Similar to wordpress and other software. It would highly improve user experience for roundcube plugins.
This doesn't need to exist now, but it would really be cool if this is at least possible.
Cor
On Monday, October 22, 2012 at 2:34 PM, Cor Bosman wrote:
On Oct 22, 2012, at 2:31 PM, till <klimpong@gmail.com (mailto:klimpong@gmail.com)> wrote:
On Monday, October 22, 2012 at 2:20 PM, Cor Bosman wrote:
Hey Dominic,
composer doesn't require PHP 5.3 namespaces.
foo_blah works just as nice. I'm using both "at work".
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
One thing im wondering about composer/packagist. Is there an API through which RC or a plugin can offer a plugin admin page inside roundcube. If not, I think that is a serious negative.
Whatever the plugin wants to do does not depend on the "installer"?
Or can you explain how the installer would need to be aware of it?
What I mean is, that if a roundcube installation admin logs into RC, they can see all plugins that are installed (similar to about page), but also see if new versions are available, and maybe even update right from roundcube. Similar to wordpress and other software. It would highly improve user experience for roundcube plugins.
This doesn't need to exist now, but it would really be cool if this is at least possible.
Cor
Hey,
this is *very* much possible.
This kind of feature would be a plugin itself – or could also be part of the RoundCube core.
The way it would work in a nutshell is this:
- check local .lock file from composer (= composer.lock) against installed versions
- compare against our packagist repository
I'm not a 100% sure if someone has done this before, but it's all there — or takes little effort to be build.
It's already possible to run something like that ./composer.phar update --dry-run, so I don't see why this couldn't be exposed to the web:
http://getcomposer.org/doc/03-cli.md#options-3
Till
composer doesn't require PHP 5.3 namespaces.
You got me wrong. I know that you can use composer with packages, that aren't using PHP 5.3 and namespaces. What I ment is the requirement to run composer. This requirement is 'PHP 5.3.2 or above' ( https://github.com/composer/composer#requirements )
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
Dominic
On Tuesday, October 23, 2012 at 12:55 AM, Dominic Lüchinger wrote:
composer doesn't require PHP 5.3 namespaces.
You got me wrong. I know that you can use composer with packages, that aren't using PHP 5.3 and namespaces. What I ment is the requirement to run composer. This requirement is 'PHP 5.3.2 or above' ( https://github.com/composer/composer#requirements )
Oh no! ;-)
Anyhow — I made good progress over the weekend. Hoping to publish something by Wednesday.
Dominic _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
-
Cor Bosman -
Dominic Lüchinger -
Thomas Bruederli -
till