Live data from Hacker News

Engine Yard's sponsorship of RVM is coming to an end

rvm.io

71–72 of 72 posts

Re: Engine Yard's sponsorship of RVM is coming to an end

#71

Earlier quoted context omitted.

As I said elsethread, I haven't yet considered production, but I just switched to chruby for my development environment rather than rbenv. I still use ruby-build when I need (I just needed a version not supported by ruby-install), but I have switched wholesale to chruby, and having found chgems in researching a different answer, I may look at using that as well. chruby really is the simplest possible thing you can do…

I'd argue that you don't need any of rvm/rbenv/chruby in production.

I'd agree. Something as simple as chruby makes having multiple interpreter/gemset versions easily usable from something like cron without introducing a lot more overhead, though, or having to remember to put all the variables &c. in place everywhere you need them.

Re: Engine Yard's sponsorship of RVM is coming to an end

#72

Earlier quoted context omitted.

The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.

What do you do instead of 'bundle exec' to execute ruby command line utilities using the desired dependency tree?

I've literally never found myself in a situation where the dependency tree of a ruby cli utility has been incompatible with what's in the current $GEM_HOME. As and when it happens, I'll see about giving it a separate $GEM_HOME to play with. That's the only situation I can think that binstubs in addition to what `gem install` provides make sense, too.
Post reply on HN