How to improve the Ruby on Rails experience for next Ubuntu release ?

There have been some discussions during the last two Ubuntu Developer Summits about improving the Ruby on Rails experience in Ubuntu. Thoughts have been collected in a blueprint and preliminary work has been outlined in the RubyOnRailsStack wiki page. The content deals primarily with hosting RoR applications and is based around apache2 configured as a reverse proxy for Mongrel.

A higher level issue is related to deployment workflow. The question is how can Ubuntu be improved to streamline RoR application deployment ? Every system administrator has its own scripts to deploy Rails applications – are there any patterns there ? Could these be integrated into Ubuntu ? How do you manage the development-testing-production cycle of Rails application deployment ?

The Ubuntu Server Team is looking for input of Rails users. Add your feedback to the discussion section on the RubyOnRailsStack page and help us shaping out a rock-solid RoR experience for Intrepid Ibex.

14 Responses to “How to improve the Ruby on Rails experience for next Ubuntu release ?”

  1. dr Says:

    Please don’t.

  2. Ubuntu Server Team Needs Help With Rails Experience Says:

    […] Ubuntu Server team are looking for help and advice regarding improving the Ruby on Rails experience for the next Ubuntu release. If you have opinions regarding Rails deployment, this is the time to […]

  3. Tim Says:

    Rails is under rapid development. The version that shipped with Hardy is already outdated. Rails web hosting stacks are plentiful and rapidly evolving themselves (mongrels behind nginx/Apache, thin behind nginx/Apache, mod-rails/Apache, etc.).

    Mongrel behind Apache sounds like a good choice for getting a development machine up & running, or running a small web site. As long as the different stack options are battling it out you will find that every rails developer has a different stack that they prefer.

    I would like to see Ubuntu improve their gem support or take the gems package out entirely. Right now it runs into weird issues when you run ‘gem update –system’ for example, and I wish I had just installed gems from the tar installer instead of apt.

    Nginx support is important for many people running production rails web servers. I was very happy to see it as part of the standard repositories in 8.04 but unfortunately the version shipped with Hardy is also quite a bit behind already.

  4. garg Says:

    An option would be nice just like there is an option for LAMP

  5. ralph Says:

    1. include phusion in the stack
    2. include monit in the stack

  6. Phil Says:

    It’s already pretty easy if you use nginx instead of apache and use a manually-installed rubygems instead of apt-get.

    The biggest hiccup has been the fact that the debian-packaged rubygems puts things in places that aren’t on users’ PATHs, so “gem install rails” doesn’t work as expected because the “rails” executable is not available without adding to your PATH.

    As I understand it this is just due to an insistence from Debian that rubygems be packaged in a way that is contrary to users’ expectations but compliant with LSB. I don’t know if anything can be done about this by Ubuntu except packaging a pristine rubygems instead of using Debian’s. Everyone I know installs rubygems from source instead of relying on apt-get precisely because of this issue. It would be great if Ubuntu chose to be more useful (dare I say… human?) at the expense of being LSB-compliant.

    As a ruby library maintainer, I’ve come to accept the fact that even the debs shipped with an up-to-date distro like Ubuntu will be out of date and that rubygems is often the only way to get the versions you need. Ruby libraries are developed at a very fast pace; it’s even increasing with github-distributed gems. If I were working on Ubuntu, I would simply come to embrace this and focus on making rubygems work great out of the box with Ubuntu servers rather than duplicating effort by double-packaging libraries. Being able to rely on “apt-get install rubygems” would be a great first step.


  7. Tom Says:

    Please don’t. Many developers would prefer to use Merb, Ramaze, Camping, or one of the other twenty Ruby Web frameworks.

    Do the best you can to have solid Ruby support; do not favor one Ruby Web tool over others.

  8. Leonardo Faria Says:

    my suggests:

    include mod_rails, rails and main gems.

    and if possible, nginx and mongrel.

  9. Ninh Says:

    Well, if the Ubuntu guys choose to go with Phusion Passenger(tm) (a.k.a. mod_rails/mod_rack), then those developers should be just fine seeing as it also supports Rack and even WSGI ;-). Through Rack, developers should be able to use any Ruby framework that has a Rack adapter available for it, which among many others, include Merb and Camping. The same goes for WSGI with regards to Python frameworks, which for one, allows you to deploy Django apps as well. All with the same ease of use 🙂 For more information on the features of Phusion Passenger, please see: and


    P.s. Thanks PeterC for the heads-up 🙂

  10. mathew Says:

    The best thing you could do would be to fix Ruby in general; however, that would require diverging significantly from Debian. Unfortunately, the Debian packagers were utterly unwilling to compromise and work with the Ruby developers to achieve a packaging of Ruby that actually worked properly out of the box.

  11. Neil Wilson Says:

    I have to say I’m somewhat surprised about this sort of response, when the Passenger package is already in Ubuntu REVU.

    To get that in the archive you need to be lobbying the MOTUs to get them to review the package.

  12. Neil Wilson Says:

    At Brightbox we obviously deliver Rails to customers using Ubuntu Server, and we’re quite happy for that technology to be fed back into the main release LAMP style.

    We’re working on the main problems at the moment which are

    – Rubygems not activating gems by defaults. (Already kicked off:
    – Gems standing on apt packages and vice versa
    – Lack of Phusion Passenger support.
    – Poor to non-existent mongrel cluster support.
    – Difficulty of generating apt packages from Gems
    – Which causes a general lack of packaged gems.
    – Lack of effective Rails packaging.
    – Inability to switch Ruby backends easily – again due to bad packaging support.

  13. David P Says:

    Im the author of the original spec, and wiki pages, We’ve recently decided to go with passenger/rack/apache, anyone wishing to contribute should subscribe to the spec, and shoot me an email. Thanks to the author of this for getting it out in the blogsphere.

  14. Joran Says:

    Phil has a great point. That’s an instant win. Otherwise, I’ve tried Nginx/Thin, Apache/Mongrel, Apache/Passenger, and Passenger is certainly ahead of the pack. I would prefer Nginx to Apache but for the use of Passenger, the switch to Apache is justified. Passenger is much simpler, much easier to maintain. And memory usage is certainly less. Less leaks.

Leave a Reply