The Rails Myths(loudthinking.com)
loudthinking.com
The Rails Myths
http://www.loudthinking.com/posts/29-the-rails-myths
10 comments
By coincidence, I was up until 2 last night getting a Passenger install to work. I'm deploying multiple apps to this new server I'm setting up and didn't want to install gems globally (Rails' version of DLL hell) and had all sorts of fun with freezing Rails and gems, and getting Capistrano to work.
And, yes, Passenger made this whole process easier than it was when I did this with Mongrels. It's still not simple and easy.
And, yes, Passenger made this whole process easier than it was when I did this with Mongrels. It's still not simple and easy.
It's still not easy, you mean, when you try to override the default package manager.
Yes, it is not easy to avoid the Ruby version of DLL hell.
I think it's a silly comparison you're trying to make. "DLL Hell" is "Hell" because there's a system-level depot for binaries that is hard to override. If you really need multiple global gem depots, just run multiple builds of the same Ruby.
The first thing every team I've worked on has ever done with Ruby (and Python and Tcl before that) is roll a project-specific Ruby build, so that nobody is working off the polluted system Ruby. It was even worse with Python, which for a couple years was a whole major version back from mainstream Python.
I'm not saying there isn't a real problem here; if you're hosting apps for 3 different teams, you do have to do a little dance to deploy seamlessly for all 3 of them with all their deps.
But most teams are never going to run into this problem, and I don't know of a really elegant solution for it.
The first thing every team I've worked on has ever done with Ruby (and Python and Tcl before that) is roll a project-specific Ruby build, so that nobody is working off the polluted system Ruby. It was even worse with Python, which for a couple years was a whole major version back from mainstream Python.
I'm not saying there isn't a real problem here; if you're hosting apps for 3 different teams, you do have to do a little dance to deploy seamlessly for all 3 of them with all their deps.
But most teams are never going to run into this problem, and I don't know of a really elegant solution for it.
To my ears, you're describing "DLL hell", but saying that it isn't really DLL hell, because you can work around it, and because the problems are just as bad in some other languages.
Personally, I think Rails is pretty hard to deploy. There are just too many global inter-dependencies that need to be managed.
Personally, I think Rails is pretty hard to deploy. There are just too many global inter-dependencies that need to be managed.
Well when you summarize my argument that way, it doesn't sound nearly as incisive as it did to me originally.
We build a small, versioned depot of ruby + rails and other gems. Running this with Apache/mod_fcgid works really well and is very stable.
Setting up a tightly version-controlled, centralized deployment for a full Rails app stack is more difficult than doing the same with J2EE, but this is partially due to the immaturity of the platform -- Ruby, and Rails, just haven't been in the mainstream for anywhere near as long as Java has.