Installing Rails Plugins from a Git repository

Published on and tagged with cakephp  plugin  ruby on rails

What I learned today is how you can install Rails plugins from Git repositories with a simple command:

dho@tumulux:~/projects/myrailsproject$ ./script/plugin install git://

The example command from above will download the OpenIdAuthentication plugin from GitHub and put the plugin in the vendor/plugins directory. Quite handy.

In the CakePHP world there is currently no equivalent. However, John David Anderson (aka _psychic_) recently published an early version of a Plugins shell console application to manage plugins.

Happy working with plugins!

12 comments baked

  • jojo siao

    just sharing. :p
    I tried the ruby-openid gem and installed the open_id_authentication plugin with restful_authentication. You can watch how it is being done in

  • cakebaker

    @jojo: Thanks for your comment!

    Yes, I have the ruby-openid gem and the open_id_authentication plugin successfully installed (without the restful_authentication as I currently don’t need username/password-based authentication), and it works like a charm.

  • David Harrison

    Hi Daniel, Looks like you’re making good progress with RoR. I fell in love with RoR until I started battling with deployment and mongrels and things! I’m looking forward to a post from you which covers your experience with that. I’m afraid that I retreated at that point and decided to persevere with Cake (even though the 1.2 branch had been rather unstable at that time).
    Best wishes, D

  • Nate Todd

    David: phusion passenger.

  • cakebaker

    @David: As mentioned by Nate, I would try Phusion Passenger. It’s quite easy to setup. And from what I read the deployment is almost as simple as with PHP: upload your files to the server, and touch tmp/restart.txt to restart the application.

    Maybe it is time to reconsider Rails? ;-)

  • Nate Todd

    I have been working with cake since early 2007 and I just switched to Rails in December. I love what cake did to my php and will use cake any time I am forced to use php. However, there were several reasons I switched to rails for my current work.

    1. Deployment on Passenger. Passenger is a godsend. It makes deploying rails applications as easy as php. You drop your files on the server, set up the vhost, and you’re in business. No messing around with capistrano (unless you need to run rake tasks or other deployment scripts) and you can just set up the server as a git repo or remote. This is the #1 reason I switched at the time I did. Deployment is solved.

    2. Core development speed. The cake guys are really hard workers and very careful about the code they release, so kudos to them. But rails has a lot more people hacking on the codebase and submitting patches. Releases with meaningful features come a lot faster. I think 2.3 RC1 was only 10 weeks after 2.2 and there is a lot of stuff in 2.3 that I am already enjoying. The development occurs at a significantly faster rate.

    3. IRB. With cake you end up putting a lot of debug and pr() statements everywhere to debug your code. There might be better ways (like integrating with firebug), but none match the ability to just hop into irb and run your code there. “script/console” will run IRB with your rails app loaded in and you can just test everything there. It is truly an amazing thing the first time you see it and I can’t imagine working without IRB in the future.

    4. Flexible templating. I know cake can work with smarty and possibly other templating engines, but I doubt the integration is as easy as rails. Put “gem.config ‘haml” in your environment, run “rake gems:install” and you can now start templating with haml (haml rules BTW).

    5. Gem requires. In current rails apps, you can just use “gem.config” to manage gem dependencies. (RubyGems is roughly equivalent to Pear, but much easier to use) Running “rake gems:install” will install all gem dependencies for your application, so deploying all your gems to new machines is as easy as running a single command. It is extremely handy.

    6. Plugins. Cake has some fantastic plugins, but nowhere near the amount available for rails. In fact, it can be overwhelming sometimes. Rails finally just added support for full plugin stacks, so you can drop all your MVC files and routes in your plugin. Plugin support is also very nice as you have covered above. You can also scaffold plugins and “script/plugin destroy foo” will wipe a plugin out. You can also load in your pugins as git submodules, but that isn’t rails specific.

    7. Github. This isn’t rails’ fault, but github has become the defacto standard for rails projects and gems. It’s a great site, so this is just an added plus.

    8. Rails 3.0. Rails is merging with the #2 ruby framework, Merb. Merb brings a lot to the table in the form of performance and flexibility. Rails 3.0 will allow users to modularize their stack and drop in any ORM they want and just put together the stack they need instead of the full default stack. There are some really nice activerecord alternatives out there (especially for cloud services and key/value DBs) so this is a huge win. Merb also has been very performance oriented, so the optimizations are already making their way into rails edge. Rails 3.0 should have a preview out by may.

    9. Other ruby frameworks. There are some absolutely stellar ruby frameworks out there. I have built several applications with Sinatra in the last couple weeks. Sinatra totally changes how apps are designed by providing a DSL suitable for microapps. I built in about an hour one day. I put the source on github (linked form the app’s footer) if you want to see what I mean about microapps.

    10. Rack. Rack is a ruby interface to webservers that nearly all ruby frameworks are using these days. Rack is extremely cool in that it allows you to run multiple applications together and define explicit routes and failover routes (if an app returns a 400, move to next app). This allows you to write smaller apps that do certain things extremely well. Imagine a rails app for the CMS, a sinatra app that runs really fast for feeds, and another Sinatra app that handles file uploads and spawns processing for them (ffmpeg, Imagemagick, etc.). Not only do you get to use the right tool for the job, you can reuse all your microapps.

    11. Production use. Cake has plenty of juice and I would never say php can’t scale. But ruby has finally proven itself over the years and now has a lot of research and code behind scalability. There are some very high-end tools to use for all your typical growing needs (memcached and other key/value stores, sharding, etc). At best this is a tie, but it should be brought up that rails can scale now. :)

    12. REST + respond_to. Rails native support for RESTful resources is HUGE. I mean, HUGE. You are basically provided an XML API for free. This can be json with a 2-second change. Huge. Takes some getting used to 7 controller actions instead of 4, but it is so much more powerful and makes ajax with jquery/xml a one-line affair (steer clear from built-in prototype helpers).

    13. Testing. Cake has testing facilities, but nowhere near the flexibility as rails. Extremely easy to drop in rspec, shoulda, factory girl, your-lib-here as testing facilities, or just use the built-in test unit. I personally use rspec for TDD with autotest. As soon as I save my code in textmate, autotest runs and outputs a growl message that tells me if I passed, failed, or have pending tests. Fully automated test suite FTW. Rspec also has rails helpers that allow you to scaffold with rspec tests instead of test unit tests.

    14. Ruby. I love ruby. You might love php, so that’s cool. It’s a plus in my mind, however.

    Now, some negatives:

    1. Cake documentation > Rails documentation. Cake book wins, hands down. Rails has some new guides coming up on for rails 2.3, so that’s a good place to check.

    2. Rails hm, bt, habtm relationships require more work. Cake does a nice job of view helpers to get the selects set up. Rails is not so kind. BTW, habtm is pretty much depricated in rails due to has_many_through. Check it out to see the awesomeness of hmt.

    3. Bakery > Rails wiki. The wiki is a ghetto.

    4. RAM. Ruby ♥ RAM. Need some beefy servers to handle load.

    There are many more points for both sides, but hopefully this is a useful writeup from a person living in both worlds.

  • David Harrison

    @Nate Todd

    Thanks so much for your thoughtful comparison of RoR vs Cake. One thing is for sure, things have been moving along dramatically in the RoR world while Cakephp 1.2 has been under development. I will certainly give RoR another look and reconsider what difference Phusion Passenger would make to the equation.

    Interesting about your view of Cake’s documentation. Previously, this was always considered one of Cake’s weakest points. It is a great tribute to John Andersen and the documentation team at Cake to have come so far.

    @Cakebaker. I’m pleased that you are spending time looking at the virtues of other frameworks. I have also been very impressed by the progress of Yii. However, there is also a great danger that one can spend all one’s time reviewing frameworks but not actually getting any work done!

    Best wishes, D

  • cakebaker

    @Nate: Thank you for your comprehensive comparison! You should put it into an article on your blog ;-)

    1. Yes, I fully agree.

    2. Yes, Rails has the advantage of more man power. Though more developers doesn’t necessarily mean the development occurs at a faster rate. CakePHP has more contributors than in the past, and still it seems to me like the development has slowed down.

    3. CakePHP also provides a tool to debug stuff (“cake console”), though I doubt it is used often. And it is less powerful than IRB.

    6. Nice, didn’t knew about the “full plugin stacks”.

    8. Yes, Rails 3.0 sounds promising.

    9. I heard about Sinatra, however, so far I didn’t investigate it further. It seems, I have to have a look at it ;-)

    10. The first time I hear about Rack. Sounds interesting. Thanks for mentioning it!

    13. Yes, the Rails world is definitely more “test-infected” than the Cake world. And that’s something I really like.

    Regarding the documentation, I think both projects have their strengths and weaknesses: the cookbook and the bakery are good resources for CakePHP, whereas for Rails the API documentation is very comprehensive, and also the guides are nice.

    Once again, thank you for your writeup, it contains several points I have to investigate further :)

    @David: Yes, that’s a real danger and I’m aware I have to be careful not to do too much things in parallel…

  • Nate Todd

    3. Yeah, console is pretty much useless compared to irb.

    6. Typo. It’s “script/plugin remove foo”, not destroy. Destroy is used pretty much everywhere else in rails (like destroying scaffolds), so remove is a bit out of place. Run “script/plugin” with no arguments for more commands.

    9. Sinatra is mind-blowingly cool. I was talking to the lead on IRC the other week and they have some very cool additions coming that will allow you to map routes like rails and group actions if you need to grow it. I actually have a client job for whick I am considering using Sinatra since it’s pretty low-key. Also, check out The sinatra leads work there and it’s very easy to use.

    No problem. I might actually clean some of this up and put up on my blog. Thanks for the discussion to refine my thoughts!

  • David Harrison

    I enjoyed the Heroku analysis about deployment time as a proportion of total project time. I suppose it couldn’t have been based on PHP projects though. The Heroku ideas about coding through a browser and instant deployment on Amazon etc also sound brilliant (as long as it’s more than vapour!).

    I guess the PHP world just takes easy deployment for granted, so maybe that’s not such a strong selling point to them. However, IMO Heroku (and Passenger) do remove the main barrier for RoR uptake and may spark a new surge of interest in RoR now – it certainly did with me :-)

  • Nate Todd


    The deployment equation covers far more than just the inclusion of mod_php with a managed hosting provider. Their definition of deployment covers the provisioning of hardware, the lockdown of the OS, and the stack setup of a mid to large sized web application. The factors would still be involved with a php application of the same scale and the php-specific portion is just a tiny percentage of that.

    I have developed both small company sites on shared hosting and large dedicated systems on corporate IT infrastructure, and I can say that there is a huge disparity between the two. Passenger finally brings rails deployment in line with php deployment on the smaller shared-environment setups. Heroku is hoping to solve those larger-scale time consuming deployments and provide flexible scaling via EC2. Having currently spent the last 3 months working tirelessly with an unnamed US government IT department and security contractors to deploy an app (cake app actually…) that took only 2 months to build, it’s very attractive indeed.

  • cakebaker

    @Nate: Thanks for mentioning Heroku, didn’t knew this project yet. Sounds a bit like the Aptana Cloud for PHP.

Bake a comment

(for code please use <code>...</code> [no escaping necessary])

© daniel hofstetter. Licensed under a Creative Commons License