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

31–40 of 115 posts

Re: Rbenv, an unobtrusive rvm replacement

#31

Post by sanderjd »

alrs wrote: post #19
heimidal wrote: post #14

Earlier quoted context omitted.

I know very few people using the distro version of Ruby in production. Most are using either rvm (not so desirable) or a custom-compiled version (more desirable). In my experience, the version of Ruby shipping in most Linux distros and package systems is outdated or less than ideal for production use.

Apt-pinning and source packages are great ways to bring newer Ruby in to Debian stab The first thing I did after you left our common former employer was ditch all of the manually-installed REE on Ubuntu and changed to Debian stable with .debs of ruby and rubygems pinned in from testing. It was an improvement.

I'm not familiar with the technique you're referring to, is there a reference you could point me to that discusses "apt-pinning" packages from testing? We recently had a "there must be a better way" moment trying to get a standardized Ruby 1.9.2 installation set up - I think what you're describing is that better way.

Re: Rbenv, an unobtrusive rvm replacement

#32

Post by moe »

alrs wrote: post #23
xentronium wrote: post #11

Earlier quoted context omitted.

> I don't see a pressing need to use RVM in production 1. Gemset isolation comes in handy. 2. Sometimes you want to have multiple ruby versions (e.g. MRI for app and JRuby for memory heavy script)

Debian allows you to install ruby MRI and jruby simultaneously.

Recommending RVM for production use is hilarious.

Recommending debian-ruby for production use is bordering on physical injury.

Re: Rbenv, an unobtrusive rvm replacement

#33

Post by sstephenson »

chc wrote: post #27

I'm having trouble imagining who this is for, at least in the context of an RVM replacement. The point of RVM is convenience. It's like RVM, only without most of the convenience (gemsets, installing standard versions and migrating between versions, primarily). If I wanted to manually manage all my Rubies, I wouldn't be using RVM. I like the sentiment of being less of a hack than RVM, but I just don't see much use for…

The main use case is for specifying per-application Ruby version dependencies. For example, at 37signals, most of our apps run on REE, but our new apps run on 1.9.x, and we're gradually moving everything to 1.9. When you have multiple people working on multiple apps every day, it's essential that this dependency information is checked into version control. Even more so when certain branches of an app may depend on different versions.

Both rvm and rbenv allow you to specify per-application dependencies (rvm with .rvmrc files, rbenv with .rbenv-version files). The difference is that rbenv does it in a much simpler, less invasive way.

Re: Rbenv, an unobtrusive rvm replacement

#34

Post by sstephenson »

sanderjd wrote: post #29
alrs wrote: post #22

Earlier quoted context omitted.

apt-get install ruby1.9. It's in there.

1.9.1 is there, 1.9.2 is not. But I still the the better solution is to build from source on each machine, or create a custom 1.9.2 package for the machines you will be using. As other comments have pointed out, RVM is held together with string and duct tape and breaks frequently. I haven't dug into the code from this project, but being more testable and maintainable would be one of the biggest wins they could achiev…

That's the goal, and that's why rbenv does not perform compilation/installation at all (there's a separate ruby-build project for that: https://github.com/sstephenson/ruby-build).

Re: Rbenv, an unobtrusive rvm replacement

#35

Post by sanderjd »

damoncali wrote: post #28
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…

I'll take your word for it. For me, it mostly saves me a bunch of time. Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use. Double Edit: "a bunch" is probably an…

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.

Re: Rbenv, an unobtrusive rvm replacement

#36

Post by stephencelis »

nzadrozny wrote: post #26
jarin wrote: post #17

Pretty nice, but I actually do really like having gemsets. It gets me as close to the production environment as possible, plus it makes it really easy to clean up unused gems when I'm done with a project.

For that, I use Bundler and always install gems to vendor/bundle for maximum isolation and easy cleanup. :~ which bi bi: aliased to bundle install --path vendor/bundle

(You should only have to run this the first time you bundle.)

Re: Rbenv, an unobtrusive rvm replacement

#37

Post by moe »

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…

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.

Re: Rbenv, an unobtrusive rvm replacement

#38

Post by epochwolf »

sanderjd wrote: post #35
damoncali wrote: post #28

Earlier quoted context omitted.

I'll take your word for it. For me, it mostly saves me a bunch of time. Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use. Double Edit: "a bunch" is probably an…

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.

Re: Rbenv, an unobtrusive rvm replacement

#39

Post by nona »

sanderjd wrote: post #29
alrs wrote: post #22

Earlier quoted context omitted.

apt-get install ruby1.9. It's in there.

1.9.1 is there, 1.9.2 is not. But I still the the better solution is to build from source on each machine, or create a custom 1.9.2 package for the machines you will be using. As other comments have pointed out, RVM is held together with string and duct tape and breaks frequently. I haven't dug into the code from this project, but being more testable and maintainable would be one of the biggest wins they could achiev…

I have to contradict you (unless I'm misunderstanding you): the debian package named ruby1.9.1 is actually 1.9.2. The 1.9.1 refers to the ruby ABI. Blame the ruby devs for breaking the ABI in a minor version update (1.9.0 -> 1.9.[12]).

Re: Rbenv, an unobtrusive rvm replacement

#40

Post by alrs »

sanderjd wrote: post #31
alrs wrote: post #19

Earlier quoted context omitted.

Apt-pinning and source packages are great ways to bring newer Ruby in to Debian stab The first thing I did after you left our common former employer was ditch all of the manually-installed REE on Ubuntu and changed to Debian stable with .debs of ruby and rubygems pinned in from testing. It was an improvement.

I'm not familiar with the technique you're referring to, is there a reference you could point me to that discusses "apt-pinning" packages from testing? We recently had a "there must be a better way" moment trying to get a standardized Ruby 1.9.2 installation set up - I think what you're describing is that better way.

http://jaqque.sbih.org/kplug/apt-pinning.html
Post reply on HN