Deployment is a …

Debugging remote deployments is really painful. (Big surprise there, I'm sure.)

The root of my problem is that I've allowed my development environment and my deployment environment to diverge. That's never good. As the old joke goes, the patient says to his doctor, “Doctor, doctor, it hurts when I do this,” and the doctor replies, “Well, then, don't do that.”

I have always planned to deploy the photographic metadata code I've been hacking at on photodata.org. As I'm hosting that at DreamHost, I have little control over the deployment environment. Unfortunately I didn't notice that they're running Ruby 1.8.2 where I'm running 1.8.5. In fairness, even if I had, I might not have expected the difference to bite so hard.

Something is different in the net/http library. The code I wrote in 1.8.5 for providing a body to an HTTP post doesn't work on 1.8.2 (which doesn't seem to provide a body= method on HTTPRequest).

I looked at the 1.8.2. version of net/http and decided to punt, that is, to build 1.8.5 on DreamHost. (I'm pretty happy with DreamHostI wish they included mod_conneg in their Apache config, though. in part because I can build and use my own stuff there.) The find, download, unpack, configure, build, install dance for Ruby is pretty straightforward.

Of course, then I find that there are a bunch of gems missing. Luckily gem install works just fine (it doesn't on my laptop for reasons I've never been able to adequately understand).

But the RMagick gem (which, ironically, won't actually be used on the web-deployed version but is needed for making thumbnails when annotating images on the local filesystem), won't install because the version of ImageMagick is too old.

How far back does this chain of prerequisites go, exactly?

I had this terrible feeling that ImageMagick was going to be much more difficult to install. It wasn't, perhaps mostly because I don't really care if it works or not. That usually helps in software development.

Dance, dance, dance…