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.
Please don’t.
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.
An option would be nice just like there is an option for LAMP
1. include phusion in the stack
2. include monit in the stack
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.
See https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/145267
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.
my suggests:
include mod_rails, rails and main gems.
and if possible, nginx and mongrel.
@Tom:
. 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: http://www.modrails.com/ and http://phusion.nl/assets/phusion_rubyenrails2008.swf
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
Cheers,
Ninh
– Phusion.nl
P.s. Thanks PeterC for the heads-up
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.
I have to say I’m somewhat surprised about this sort of response, when the Passenger package is already in Ubuntu REVU. https://bugs.edge.launchpad.net/ubuntu/+bug/246719
To get that in the archive you need to be lobbying the MOTUs to get them to review the package.
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: https://bugs.edge.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267)
- 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.
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.
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.