you might want to just lock therubyracer to 0.10.x

Rails, with the asset pipeline in Rails 3.1, started requiring the presence of a javascript runtime in order to compile assets (and oddly, for reasons I never figured out, just to boot your rails app even without precompiling assets).

And even back then, people said, really? you want to require a javascript runtime for out of the box rails to work?

But with the beauteous ease of use of `therubyracer` gem, it wasn’t that bad: Oh, quit your bellyaching, just add `therubyracer` to your Gemfile, and you can forget about it.

And that was indeed always true in my experience and observation, just add `therubyracer` to your Gemfile,  I never encountered a situation where it wouldn’t install/compile, even though it was always a ‘native’ gem. (therubyracer is a ruby wrapper for the v8 javascript interpreter).

Except, um, not with 0.11.0.  People everywhere are having a hellova time getting therubyracer 0.11.0 installed.  I honestly don’t really know/understand what changed with 0.11.0 — I guess depending on a new version of v8, but I’m not sure what makes the new version of v8 harder to get to install transparently Just Works than the old one.

But I’m seeing reports from downstream users of software I commit to (built on rails) “hey, it says it needs to install therubyracer adn can’t, what do I do?”  And some software that was including therubyracer in it’s built on travis — it fails on travis too   (I have no idea if you really need therubyracer on travis, there might be another js runtime there already, it’s just another example of a system that 0.10.0 built on but not 0.11.0. )

All my existing projects had Gemfile.lock’s with 0.10.x’s in them, but I figured, okay, let’s give it a try. 0.11.0 won’t compile on my RHEL5 box (don’t ask why I’m on RHEL5, but previous versions of therubyracer never had a problem with it, or with nearly anywhere else) — it first tells me that I need to compile v8 from source because it’s not on my system (how did 0.10.x get around that?), but tells me I can use the gem “libv8″ to do that for me — but I try to gem install libv8, it fails to compile from source, and seems possibly to be complaining that I don’t have a recent enough version of `g++` installed.

Oh, I know how this kind of unix/C dependency hell goes…. but I need to go through it just to get an out of the box standard Rails app up and running? Really?

Well, no, not if I just lock to therubyracer “~> 0.10.x” in my Gemfile. That’s what I plan to do until when and if therubyracer manages to figure out how to become as easy to install as it used to be (or until things start requiring newer versions of therubyracer for some reason; if at that point, it’s still hard to install… I guess I’ll start looking into how to turn off the parts of rails that require a JS runtime?).

Sadly, newbies to Rails won’t know to do that, and it’ll just be one more barrier to getting started on Rails, one more of many that have arisen since Rails 1.x or even 2.x days. But if I see a question “why can’t I get Rails to work?” that’s due to this, my answer is going to be “just stick this in your Gemfile to lock to the old version of therubyracer”.

About these ads
This entry was posted in General. Bookmark the permalink.

6 Responses to you might want to just lock therubyracer to 0.10.x

  1. Mike Boone says:

    Thanks for the post! This issue wasted a couple hours of my day. I couldn’t figure out why other Rails 3 apps were happily running on the same server, but not my new one. 0.10.x did the trick.

  2. I’m with Mike… had the same problem on a second server today.
    Installed Node.js and removed therubyracer, Execjs did the trick.
    But after some time I needed to ship some changes in other projects and just ended up locking therubyracer too.

  3. Yoav says:

    hmm… was getting some intermittent segfaults with therubyracer 0.10.2, and this issue https://github.com/cowboyd/therubyracer/issues/209 seems to suggest the fix is to upgrade to 0.11…

    Luckily the segfault looks quite rare, but am feeling a bit stuck between the rock and the hard place. I’m wondering why it’s actually required for production, other than precompiling the assets (after which, I guess it’s no longer needed??). Otherwise, perhaps it’s time to consider installing node on our production hosts?

  4. jrochkind says:

    Yoav, I _think_ therubyracer problems have been resolved in the latest 0.11.2. Give it a try.

    I don’t entirely understand what, where, and why a js runtime is required for in rails either.

  5. Yoav says:

    Thanks for the quick reply Jonathan, I’ll give 0.11.2 a try. Only encountered this segfault recently, and whilst searching online for info about it I bumped into your blog. Haven’t given much thought to therubyracer until now, but thought that doing a bit of research before upgrading is always a good idea, because you never know what surprise(s) might lie ahead…

  6. jrochkind says:

    as the problems I posted about were problems with installation that either you’d have or you’d not have, the most efficient thing to do would be to simply try it. If it works, then it works.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s