Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rbenv, an unobtrusive rvm replacement

github.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Rbenv, an unobtrusive rvm replacement

#81

Post by revscat »

axomhacker wrote: post #60
revscat wrote: post #25

This looks promising because it looks like it will work seamlessly with tmux/screen, something rvm struggles with.

What problems did you see using rvm with screen? I use that daily and haven't seen any problems so far.

I am currently porting a Ruby application over to JRuby, and use tmux (although I am pretty sure screen would behave the same). Let's say you have two rubies installed, ree and jruby. You start out using ree, and are using screen/tmux, and have two screens open.

If you switch to JRuby in the first screen, then switch to the second, the changes don't propagate. e.g.:

(first screen)

  $ rvm list

  rvm rubies

  => jruby-1.6.3 [ darwin-i386-java ]
     ree-1.8.7.2001.03 [ x86_64]
(second screen)

  $ rvm list

  rvm rubies

     jruby-1.6.3 [ darwin-i386-java ]
  => ree-1.8.7.2001.03 [ x86_64]
It's not a big deal -- you just have to make sure you do the right thing -- but it is unexpected and has burned me a couple of times. It looks like rbenv won't suffer from this problem.

Re: Rbenv, an unobtrusive rvm replacement

#82

Post by Cloven »

jsavimbi wrote: post #71
yariang wrote: post #55

Earlier quoted context omitted.

I looked at RVM a few weeks back while trying to set up a Rails app and was so frustrated I went outside and kicked a kitty. I am glad to see a project that should restore some of my sanity. Good work.

If you couldn't figure out RVM, you probably shouldn't be playing with Ruby.

With all due respect, ruby is a language, and rvm is a collection of really fragile and dangerous shell script hacks.

Re: Rbenv, an unobtrusive rvm replacement

#83

Post by Cloven »

metaskills wrote: post #72
rsanheim wrote: post #16

Earlier quoted context omitted.

In most cases you shouldn't have RVM in "production" any way.

To be fair, Wayne has always said that RVM was made for production first and development second. Not sure if it is fair to say it is not production ready since it has always been geared toward just that.

It doesn't matter what Wayne has always said. He's designed a collection of fragile shell script hacks that want to be run as root that fundamentally change the behavior of key system commands.

Re: Rbenv, an unobtrusive rvm replacement

#84

Post by kunley »

alrs wrote: post #15
damoncali wrote: post #12

Earlier quoted context omitted.

Why not?

Because going back to non-packaged non-vetted flavor-of-the-month code is a retrograde step back to 1993. You lose consistency, you lose the ability to reliably recreate a same environment, you lose tested and low-friction security updates, you lose dependency management, you lose the security of a crypto web-of-trust, and you lose the google-fu of being on the exact same versions of software as thousands of other pe…

I'd tend to agree, with one exception: it's sometimes even more desirable to construct own /usr/local version of some critical packages (database, languages, crucial libs) instead of distro versions; then recreate this on your all production nodes and never upgrade it without a carefully thought reason and pre-prod test.

Two main reasons for this:

- sometimes the version provided by the distro doesn't have set of features which you need and careful admin can provide it for you,

- sometimes distro packagers or upstream folks violate semantic versioning (incidentally or not) and upon upgrade from distro, some of your sub-features ("sub-" doesn't have to mean "not critical") break.

Of course you lose the google-fu you've mentioned, but to be honest, many production environments are so distinct that there's no sane way to compare one to "typical Debian X.Y server".

I personally find FreeBSD approach very convenient wrt to the issues above, because ports evolve independently from the base system; but YMMV.

Re: Rbenv, an unobtrusive rvm replacement

#85

Post by PatrickTulskie »

Cloven wrote: post #83
metaskills wrote: post #72

Earlier quoted context omitted.

To be fair, Wayne has always said that RVM was made for production first and development second. Not sure if it is fair to say it is not production ready since it has always been geared toward just that.

It doesn't matter what Wayne has always said. He's designed a collection of fragile shell script hacks that want to be run as root that fundamentally change the behavior of key system commands.

You don't have to run them as root. You can run them as a regular user. I'm pretty sure Wayne recommends against RVM system-wide and the preferred method is just installing it for individual users.

Re: Rbenv, an unobtrusive rvm replacement

#86

Post by Gibheer »

revscat wrote: post #81
axomhacker wrote: post #60

Earlier quoted context omitted.

What problems did you see using rvm with screen? I use that daily and haven't seen any problems so far.

I am currently porting a Ruby application over to JRuby, and use tmux (although I am pretty sure screen would behave the same). Let's say you have two rubies installed, ree and jruby. You start out using ree, and are using screen/tmux, and have two screens open. If you switch to JRuby in the first screen, then switch to the second, the changes don't propagate. e.g.: (first screen) $ rvm list rvm rubies => jruby-1.6.3…

But thats exactly, what I expect from rvm. When i'm in in one projecti want too to use that Ruby with that gelder and not the other Ruby and gemset. So rbvm is not want I want to use with tmux.

Re: Rbenv, an unobtrusive rvm replacement

#87

Post by regularfry »

moe wrote: post #37
alrs wrote: post #15

Earlier quoted context omitted.

Because going back to non-packaged non-vetted flavor-of-the-month code is a retrograde step back to 1993. You lose consistency, you lose the ability to reliably recreate a same environment, you lose tested and low-friction security updates, you lose dependency management, you lose the security of a crypto web-of-trust, and you lose the google-fu of being on the exact same versions of software as thousands of other pe…

Your arguments sound nice in theory. Yet I don't know a single ruby shop who runs with a distro-packaged ruby, even though REE is available as a .deb.

Count us in. We only use packaged ruby, be that MRI or JRuby.

Re: Rbenv, an unobtrusive rvm replacement

#88

Post by regularfry »

Cloven wrote: post #83
metaskills wrote: post #72

Earlier quoted context omitted.

To be fair, Wayne has always said that RVM was made for production first and development second. Not sure if it is fair to say it is not production ready since it has always been geared toward just that.

It doesn't matter what Wayne has always said. He's designed a collection of fragile shell script hacks that want to be run as root that fundamentally change the behavior of key system commands.

Root? I don't think I've ever run RVM as root. Why does it need to? Not saying you're wrong, I just don't know what you're referring to.

Re: Rbenv, an unobtrusive rvm replacement

#89

Post by revscat »

Gibheer wrote: post #86
revscat wrote: post #81

Earlier quoted context omitted.

I am currently porting a Ruby application over to JRuby, and use tmux (although I am pretty sure screen would behave the same). Let's say you have two rubies installed, ree and jruby. You start out using ree, and are using screen/tmux, and have two screens open. If you switch to JRuby in the first screen, then switch to the second, the changes don't propagate. e.g.: (first screen) $ rvm list rvm rubies => jruby-1.6.3…

But thats exactly, what I expect from rvm. When i'm in in one projecti want too to use that Ruby with that gelder and not the other Ruby and gemset. So rbvm is not want I want to use with tmux.

This is in the same project.

Re: Rbenv, an unobtrusive rvm replacement

#90

Post by nirvdrum »

epochwolf wrote: post #38
sanderjd wrote: post #35

Earlier quoted context omitted.

This is kind of a classic "fast, correct - choose one" debate. If saving time is more important, perhaps you should use RVM in production, if correctness is more important, you probably shouldn't. It comes down to how expensive your mistakes are.

If you only have one server and can script most of the install process it's not a problem. When you have more than one server, rvm is not going to save you time.

I have my gripes with RVM, but this isn't one of them. I work on a project for provisioning and deploying EC2 servers. It's a capistrano plugin called rubber.

In any event, the immediate benefit is we can provide a tool that lets our users set up whatever Ruby they want to use, as we shouldn't be forcing that on them. Moreover, it makes it dead simple to deploy different Rubies out to different parts of the cluster, since everything is role-based. That's far from the common use case -- most people use the same Ruby everywhere. But if you have more complex needs, RVM affords a lot.

Post reply on HN