Hacker News Reader

Comment by alrs | Hacker News Reader

The best example of why the rvm model fails on the dev side is nokogiri.

Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri.

Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.

View on HN

Do you deploy with Vagrant? I think container might be the way forward, but I am not convinced, and I don't deploy Vagrant to production(containers might be the future for deployment but Vagrant in it's current state isn't). I don't use vagrant in production because I use a Ubuntu box for development and rvm/bundler, virtualenv/pip...cover my needs for maintaining different and isolated dev environments.

No, I don't deploy with Vagrant. Nor would I.

Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.

Yes, but that won't solve when I have 2 applications deployed on the same production box. rvm solves it.

"Solves" in the same vein of "There, I Fixed It."

http://thereifixedit.blogspot.com/

I don't see any point in conversing any further since you are being intentionally obtuse. apt-get doesn't help me with different projects using different ruby interpreters and isolated gemsets(and it shouldn't); rvm does. I deploy multiple applications to the same production box, rvm solves multiple interpreters and gemsets, I use it. Your diatribe about package management and rvm is responding to imaginary arguments. Also, package management doesn't keep up with Ruby releases and I would rather install from rvm then packaging my own and having a separate apt server. And as pointed out many times, it's not just about the interpreters but isolating gems.

Addressed: https://news.ycombinator.com/item?id=6505227

I don't work in a Ruby shop anymore, but I'd look at Bundler if I was looking to manage multiple gemsets on the same installation. As I point out in the above thread, maintaining multiple gemsets on the same machine is an antipattern that points to technical debt.

Ruby 1.8 is over. EOL. You need to port everything forward or suffer the consequences.

> Addressed: https://news.ycombinator.com/item?id=6505227

False dichotomy. There is no technical debt. Both Ruby 1.9.3 and Ruby 2 are functional and used in production. It will take some time to totally move to 2, and when that happens, there will be applications on different release versions of 2. I don't want to wait for os packaging to use a new ruby release, and I don't want to be forced by the packaging to use a particular version(older or newer).

> I don't work in a Ruby shop anymore, but I'd look at Bundler

Um. I use Bundler along with rvm.

> maintaining multiple gemsets on the same machine is an antipattern that points to technical debt.

Having a restriction of not more than one app on one machine is as stupid as it gets.

Say App 1 requires libxml 2.8.1 and App 2 requires libxml 2.9.

How does rvm fix that?

No it doesn't. But throwing away RVM doesn't fix the things RVM fixes. RVM doesn't solve all problems; that doesn't mean it isn't useful for problems it solves.

FWIW, current nokogiri 1.6.0 bundles and compiles its own libxml.

Reply on news.ycombinator.com