18 August 2006
Rails plugin repository *is* on the way
Ryan Daigle speculated on his blog that an official Rails plugin repository was in the works. He referred to an app checked into the Rails subversion repository recently.
I can announce that a Rails plugin repository is on the way, although not the one currently in the Rails repository. That particular app was a repository started by Rick Olson. The repository that is on the way is actually being worked on by myself and James Adam of Rails Engines fame.
Background and motivation
To give a bit of background to this; the idea of an official plugin repository was born out of a conversation between Rick Olson, James and Geoffrey Grosenbach at RailsConf. Work had already begun on improving the Rails plugin mechanism with RaPT, a project run by Geoffrey, James and Ben Curtis. I recently joined the RaPT team and after some discussion with the rest of the team, James and I started development on the project.
Some people may ask why an official repository is needed. Ben Curtis currently maintains a good repository of his own however it is unfair to rely on one person to keep the repository running. As more and more people use, develop and rely on plugins, the existing setup – a wiki page – is simply not scalable or maintainable. Plugins are the number one way of adding/changing Rails functionality without having to submit patches to the core – something that DHH actively encourages and something I fully support. I believe the core should be as lean as possible with additional functionality being provided by plugins.
Our original idea was to develop a plugin repository that sat somewhere between Rubyforge and the Mozilla Firefox extensions website – this included tagging, comments and ratings – the usual Web 2.0 suspects. However, after some discussion with the Rails core team we decided to drop those features in favour of making adding plugins as easy as possible and developing a way of detecting plugin health by gathering test run statistics to both encourage testing of plugins and make it clear how likely it is that a plugin will work with a particular Ruby/Rails version. The other downside to having ratings/comments etc. was the need to make users sign up for an account, something that is best avoided.
The other major feature that James and I felt was really important was the correct (and mostly automatic) handling of plugin releases and metadata. This includes reading plugin metadata from an about.yml file and handling plugin releases through either updates to the release number in the about.yml file or repository tags. One of the major failings of the current script/plugin tool is its inability to handle plugins that use the traditional trunk/tags/branches structure – something I feel is essential for anything but trivial plugins.
To sum up, the core functionality of the repository will be:
- Make it easy to browse plugins and view plugin/release health/compatibility
- Correctly and automatically handle plugin releases/versions and metadata
- Make adding of plugins – either single plugins or entire repositories of plugins – as easy and foolproof as possible
- Provide some Rake tasks to make it possible to announce new plugins/releases without having to go to the repository website
- Improve the script/plugin tool and make it use the plugin repository as its main source, making it possible to install plugins by simply specifying the plugin name
Current status of the project.
James and I have made good progress on the project so far. You can view where we are up to here – do bear in mind that this is still under development and cannot be considered reliable at this point. We are aiming to move the project over to the Rails subversion repository in the next few days.
I cannot give an accurate ETA on when the project will be ready to go live, but we really want to have this up and running in time for the European RailsConf. In the meantime, have a play with what we’ve done so far and get a feel for it. If you have any suggestions please do speak up as it is the community as a whole that this is aimed at.
Update: James has also put up a post on his blog about the project.
Return to home page | Check out my tumblelog
7 Comments on this article
Return to home page | Check out my tumblelog
Commenting on this article is now closed
1. Comment by Ryan Daigle on 18 Aug 2006 at 16:08
Luke, hope I didn’t force you to talk about the effort pre-maturely.
Nice work – this will be a great service to the community.
2. Comment by Luke Redpath on 18 Aug 2006 at 17:08
Hi Ryan, no thats fine; I’ve been itching to talk about it for a while now to be honest!
3. Comment by Seth on 18 Aug 2006 at 18:08
So why didn’t you choose to use gems? I understand the need to build automatic test runs and the like, but distributing and packaging the plugins seems like a perfect job for gems.
4. Comment by Luke Redpath on 18 Aug 2006 at 19:08
Seth – whilst gems would seem like a perfect tool for the job on first view, it would in fact be completely overkill for Rails plugins. Gems is great for self-contained libraries that can be installed independantly and system-wide but plugins don’t work like that.
It would be more work to try and retrofit our requirements to the existing gem system and using rubyforge as a repository for ruby plugins would muddle things; it would pollute the rubygems repository with hundreds of Rails plugins, becoming a pain for those who just want to browse plugins and those who don’t use Rails.
A separate system seemed te far more sensible choice.
5. Comment by Chris White on 19 Aug 2006 at 18:08
One suggestion. If you plan on having a website like Agile Development for browsing plugins, then it would very useful to display the contents of the README and CHANGLOG documents on the plugin page as documentation. One of the frustrations using Ben Curtis’ site is trying to figure out what a plugin does and how it works without going to the respository or hunting around on the author’s website if she even has one.
These documents present the most portable and standard means of documenting the basic functionality of a plugin. Plus from a browsing point o view it’s much better to aggregate as much useful information as possible on one page so you can easily bookmark and share the link with others—one plugin, one authoritative link.
6. Comment by ctran on 04 Nov 2006 at 21:11
So what’s the status?
7. Comment by Luke Redpath on 05 Nov 2006 at 23:11
We’re almost done. We are hoping to have it up ASAP, in time for Rails 1.2.