Hacker News Reader

Comment by steveklabnik | Hacker News Reader

One of the things that got me thinking about this was the recent security issues. I was helping people on Skype upgrade their apps, because they were new, and they got into Gem Version Hell. Only pulling in fancy gems when you need it helps when you _really_ need to upgrade, and you're not stuck figuring out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example, obviously, it could be any combination of gems) all refuse to get on board.

If you're using the default stack, the number of dependencies you have drops quite a bit.

View on HN

> twitter-bootstrap-rails, therubyracer, and libv8

Those three gems recently caused me a world of pain. I've been in and out of Rails development since the 1.x versions (more hobby projects than professional development), and once getting going was as simple as 'gem install rails'. Getting the asset pipeline to work changed that totally - I get the advantages of the asset pipeline, and once you get it working and all your gem dependencies sorted it is fine, but it took me a while to get there.

I don't even use therubyracer at all any more, personally. It's not generally neccesary; just {brew,apt-get} install nodejs and be done with it.

Same here. In aggregate, I must have spent at least a two full days getting therubyracer and libv8 working in various environments.

As a recent Java refugee, one of the things I find most painful about Rails is its dependence on native code libs. It's really a lot of work to get the dependencies sorted out, especially if you have several platforms to support (say OSX for dev, and multiple Linux flavors for staging/prod).

One thing I learned (the hard way) is to heed the advice that "rvm requirements" offers. If you install the libs that it recommends before trying to install your gems, things will go more smoothly. This may sound obvious, but when you're installing Ruby, RVM, Rails, Apache, etc, it's easy to overlook the instructions.

That says to me that understanding bundler is REALLY important.

If someone understood how bundler worked, there is NO reason therubyracer, twitter-bootstrap-rails, libv8, or any other gem should get in the way of upgrading (say for example) from Rails 3.2.5 to 3.2.11. `bundle update rails`, then check in your new Gemfile.lock

That should change nothing but Rails and rails' own upstream dependencies (not any of the ones you mention). And indeed it did that for me on a bunch of apps. If you're going up a minor or major Rails version, then your other gems (like say twitter-bootstrap-rails, hypothetically) might not be compatible with the new rails version, and you might have some dependency hell.

But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.

> But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.

Right, but it DID happen. Updating the Rails version updated the versions of other gems too. I know what you're saying, but the reality was different.

Reply on news.ycombinator.com