blog.philcrissman.com

Just found and read David Heinemeier Hansson’s post on The deal with shared hosts, and Dallas’ from Dreamhost posts on How Rails Could Be Better and his riposte. All interesting.

And, it turns out, pertinent to my own situation, as I’m currently using Dreamhost’s shared hosting, and trying to run Rails on it. This blog is the only “real” Rails app I’m running, and I didn’t write any part of it. I’ve started doing my development on my own local machine (as it seems to make a lot more sense to do it that way), but I’m obviously going to want to eventually deploy what I write to the server.

Now, with only one real exception, I’ve had little trouble with Rails on Dreamhost. Everything has mostly “just worked”. This blog stopped working for a bit, but it turned out that all I probably really should have done is re-run dispatch.fcgi.

So on the one hand, we have a group saying “Rails should be easier to run on shared hosting.” On the other hand, we have a group seeming to say, “Real Rails developers don’t use shared hosting.” (To be fair, what Hansson really said was that he’d love to see Rails run well on shared hosting and that the Rails team would happily cooperate with anyone wishing to work on that challenge.)

I’m reminded of a quote that stuck with me; it’s from Hansson’s keynote at RailsConf 2006. (emphasis added)

I don’t really think Rails currently is in a position where it should bend to the outside world. I think we’re actually working very well at bending the outside world to us.

I’m not going to try to defend or condemn that statement. Rather, I’m going to suggest that an “opinionated” framework, like Rails, would not be possible without that sort of attitude. Like it or not, I’m not sure Rails would be what it is without it.

So yes. Let’s have people who are interested and capable looking into the issue of improving the performance of Rails in shared hosting. The hosting companies will like it, and from Hansson’s post it’s clear that the Rails core team will welcome such improvements as well.

But let’s not think that Rails developers should drop everything and work on a problem which is not really “their” problem.

If you want to be able to install gems locally on a Dreamhost shared hosting plan, you should be able to do it. You’ll need to set some environment variables; here’s what I’ve done.

If you try to install a gem in your dreamhost shared hosting account, you’ll get a permission denied error. That’s because rubygems is trying to put the gem in /usr/local/lib/ruby/gems/1.8/ and, I’m sorry, but you can’t write to there. Now, you can do this:

[your-DH-server]$ mkdir ~/mygems
[your-DH-server]$ gem install some_gem --install-dir ~/mygems

This will let you install a gem, but there’s still a problem: rubygems is not going to be able to find the gems you install in that directory. You could change the GEM_HOME environment variable to point to ~/mygems (or whatever you want to call your gem directory), but that would be a bad idea: rubygems would no longer be able to find the gems that are already on the Dreamhost server (and there are quite a few). Also, GEM_HOME (as I understand it) should only point to one gem repository. However, there is another environment variable, GEM_PATH, which can have multiple directories in it. So, we’ll do this:

Basically, what you just did is tell bash to set a couple environment variables as soon as you start a new shell, ie, any time you log in with ssh, for example. By setting GEM_HOME first, and adding it to GEM_PATH, you make sure that all Dreamhosts gems will still be findable. So will yours.

Now, other than to confirm that this all seems to work, I haven’t tested this extensively, yet. Use at your own risk.

I believe you can also put libraries which would normally be installed as gems into your vendor/ directory in your Rails project — Mephisto does this, for example. Presumably, this is to make Mephisto easier to install — they don’t need to have a long “howto” about installing various plugins or gems before Mephisto will work.

I started out wanting to talk about Rails on shared hosting in general, but I’ll save that for another post. If this post was helpful or interesting, please consider leaving some feedback in the comments. Also, if I have anything wrong, or if what I’ve suggested could cause some other problem that I haven’t considered, please let me know!

For some reason, this app stopped working last night. Not sure what happened… it’s possible it had to do with Rails being upgraded to 2.0.2 on Dreamhost’s servers, but now I’m not so sure. I might have been able to fix it just by killing and re-running dispatch.fcgi, which is basically “rebooting” a Rails app on dreamhost.

But, did I do that?

No. I followed some advice and froze Rails in 1.2.6, in case that was the issue. I’m not so sure it was, but in any case, initially doing that did not seem to work.

Then further into the comments on the previously mentioned advice, I saw Yet More Advice to run rm -rf vendor, which I ran without stopping to consider, well, much of anything at all.

Now, I’m a firm believer that one learns either by making ones own mistakes, or by watching other people make mistakes. So hopefully you will learn from mine. Don’t type rm -rf vendor unless you stop to look inside vendor and make sure you don’t want to keep any of it.

vendor, of course, is where plugins and locally stored gems might reside. Fortunately, when I realized this, I just went back to the original mephisto-0.7.3 tarball and recopied the original contents of vendor back to the server. Since then, everything has been fine.

Dreamhost’s support team was a great help, and were quite nice, even when I complained that they were hard to get ahold of — and it turned out that the reason I couldn’t log a ticket on the site was because I was using Firefox 3, which apparently just plain doesn’t render some of the things from their support form. Go figure — beta software that has bugs in it. So, thank you, Dreamhost support team. You are awesome, and if you visit Minneapolis I will still buy you all a coffee. But just one. You will have to share it.