Rbenv, an unobtrusive rvm replacement(github.com)
github.com
Rbenv, an unobtrusive rvm replacement
https://github.com/sstephenson/rbenv
114 comments
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 this particular set of functions
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.
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.
Every other week something goes wrong with RVM. Nothing convenient about that.
[deleted]
An official release with a web site and improved installation process should be out next week.
If you're wondering "why would I use this instead of rvm?" be sure to read the readme: https://github.com/sstephenson/rbenv#readme
If you're wondering "why would I use this instead of rvm?" be sure to read the readme: https://github.com/sstephenson/rbenv#readme
This looks very, very promising. Great work.
I've never liked how RVM overrides shell commands.
I've never liked how RVM overrides shell commands.
Looks terrific. I only wish for a way to install new rubies the same way you do it in RVM, rather than a "manual" install.
New here, but could this solve your concern? Or was this is "manual" way you referred to?
https://github.com/jamis/rbenv-gemset
https://github.com/jamis/rbenv-gemset
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.
I am glad to see a project that should restore some of my sanity. Good work.
What was so frustrating about RVM?
I just could not get it to work. I follow several instruction pages carefully. I was initially trying to follow:
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#se...
I kept getting issues with versions.
I should have specified that, I do not necessarily think it is a bad product, but it did frustrate me a lot when trying to set it up. I'm sure it has saved a lot of developers time, but I speak for myself and myself alone, and the cost-benefit for me was way off.
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#se...
I kept getting issues with versions.
I should have specified that, I do not necessarily think it is a bad product, but it did frustrate me a lot when trying to set it up. I'm sure it has saved a lot of developers time, but I speak for myself and myself alone, and the cost-benefit for me was way off.
I've had terrible trouble with RubyMine and RVM. I'm hopeful that the PATH-based approach of rbenv might be better.
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.
RVM provides a great service to people who work on multiple projects with multiple dependencies across the range of Rubies. Knowing how complicated that type of development was before RVM, I can attest that it may many people's lives a hell of a lot easier.
And if you bother to RTFM, is very easy to understand and employ every day, compared to other parts of the Ruby ecosystem who don't have a talented developer supporting the project and if you cannot understand the basics of RVM, I would be loathe to encourage you to explore those other parts of Ruby world that'll make you feel utterly incompetent.
And if you bother to RTFM, is very easy to understand and employ every day, compared to other parts of the Ruby ecosystem who don't have a talented developer supporting the project and if you cannot understand the basics of RVM, I would be loathe to encourage you to explore those other parts of Ruby world that'll make you feel utterly incompetent.
Ouch. That's a series of far-fetched statements.
For one gem dependencies can be handled through Bundles. If you mean version dependencies, I will give you that. But just because RVM's goal is great doesn't mean it's execution is flawless.
Also, I did RTFM. Do not make assumptions about why I failed to get it to work. There are a million variables when trying to get anything to work (OS, env variables, etc).
Lastly, I love feeling utterly incompetent, because it usually means I am learning a lot. Furthermore, what areas of the Ruby language are you talking about exactly?
For one gem dependencies can be handled through Bundles. If you mean version dependencies, I will give you that. But just because RVM's goal is great doesn't mean it's execution is flawless.
Also, I did RTFM. Do not make assumptions about why I failed to get it to work. There are a million variables when trying to get anything to work (OS, env variables, etc).
Lastly, I love feeling utterly incompetent, because it usually means I am learning a lot. Furthermore, what areas of the Ruby language are you talking about exactly?
It absolutely sucks.
Managing multiple versions of Ruby and all the gems is very easy manually.
RVM is a buggy collection of extremely fragile and dangerous scripts.
Managing multiple versions of Ruby and all the gems is very easy manually.
RVM is a buggy collection of extremely fragile and dangerous scripts.
Wow. Looks great. Definitely going to give this a spin.
Thanks! :)
Looks interesting. It's always been pretty amazing to me that a system like RVM remains so popular when it depends on overriding the operation of basic commands like 'cd'.
That's the main reason I'm not using RVM. I depend on `cd` to work, every time, rock solid, especially when my system is unstable. I can't risk having a dependency or bug in their `cd` script breaking my most commonly used shell command.
So then what did you use on your development machine to test your ruby apps with till now? What did you use if not RVM? I am happy that RVM exists and made my life as ruby developer much easier even if it overrides 'cd'. Also to note i never had problems with RVM. Your main reason not using RVM is poor, as if there were more options out there till now.
.bash_profile? How hard is that?
ruby==ruby 1.8.7 ruby9==ruby 1.9.2 jruby== jruby 1.6 jruby5==jruby 1.5
Yeah, real tough.
ruby==ruby 1.8.7 ruby9==ruby 1.9.2 jruby== jruby 1.6 jruby5==jruby 1.5
Yeah, real tough.
Agree - this seems like an invitation to problems. Are there any known issues with it?
for anyone curious, compare to https://github.com/wayneeseguin/rvm/blob/master/scripts/cd
Yeah it's a really interesting demonstration of something that is just so darn useful that you're crazy not to use it (on your development machine), regardless of your complaints with it.
Besides the whole `cd` override thing, I am curious why so many people are "confused" or have problems with RVM? (This is a genuine question. I've never had problems with RVM, but obviously others have, so I am curious)
I love the simplicity of Rbenv. I also love the "it's never good enough" mentality. I have not had any issues with RVM, but that doesn't mean people like Sam shouldn't try to build something better.
I think this quite reflects the whole evolution theory - something quite good is replaced by something a little bit better, which is again replaced by something a bit better, and so on, and so on, and so on.
It more so to me reflects the knee-jerk reaction of many in the Ruby community to jump to newer projects simply because they are newer. I like rvm a lot and use it all the time. I'm sure rbenv is a good solution as well. I think it's a bit premature to say it's an overall better solution.
Makes sense, though I'll stick to RVM until I change my mind - RVM floats my boat, haven't had any serios issues and I live in the shell. Bad short-term (community confusion), good long-term (evolution of initial innovation). I'm very neutral here.
I got a simple solution for all you distro vs RVM people: People who prefer to use RVM - use RVM, people who prefer to use distro - use distro. Until you have proven that a server that runs distro is 2x more valuable in $ - post on HN and we could review it again. Reminding you of that we don't live in a totally symmetric universe.
I got a simple solution for all you distro vs RVM people: People who prefer to use RVM - use RVM, people who prefer to use distro - use distro. Until you have proven that a server that runs distro is 2x more valuable in $ - post on HN and we could review it again. Reminding you of that we don't live in a totally symmetric universe.
Yes RVM is a crazy hack, but that's why I love it! Has anyone actually had problems with RVM overriding 'cd'? Has RVM changed the behavior of 'cd' in a way that was a problem for you?
Yes.
I don't know if it was due to a weird environment variable or something, but when I installed RVM it got itself into an infinite loop sometimes when I did `cd`.
I reported a bug, but the author couldn't reproduce or fix it. So now I recommend anyone who asks me not to use rvm, because it's utterly ridiculous.
I don't know if it was due to a weird environment variable or something, but when I installed RVM it got itself into an infinite loop sometimes when I did `cd`.
I reported a bug, but the author couldn't reproduce or fix it. So now I recommend anyone who asks me not to use rvm, because it's utterly ridiculous.
> Has anyone actually had problems with RVM overriding 'cd'?
I did, in two different ways. The first time, cd was returning the wrong exit status. (That is, it had become a function and was returning the exit status of its last command, rather than the exit status of the actual cd call. A common gotcha when you override shell built-ins or other commands.) The incorrect exit status caused a number of shell scripts completely unrelated to rvm to break. That made it harder to debug, obviously. The second time I had trouble, TAB autocompletion with cd was broken. At one point, rvm was doing its own autocompletion for cd, although the last time I looked, it no longer does that by default. (Yeah, just checked - that code path is still opt-in by setting rvm_cd_complete_flag=1.)
Having said that, both times when I went into #rvm on Freenode to talk to Wayne about it, he could not have been more helpful.
Having said that, I still wish that as a design decision, rvm didn't override cd.
I did, in two different ways. The first time, cd was returning the wrong exit status. (That is, it had become a function and was returning the exit status of its last command, rather than the exit status of the actual cd call. A common gotcha when you override shell built-ins or other commands.) The incorrect exit status caused a number of shell scripts completely unrelated to rvm to break. That made it harder to debug, obviously. The second time I had trouble, TAB autocompletion with cd was broken. At one point, rvm was doing its own autocompletion for cd, although the last time I looked, it no longer does that by default. (Yeah, just checked - that code path is still opt-in by setting rvm_cd_complete_flag=1.)
Having said that, both times when I went into #rvm on Freenode to talk to Wayne about it, he could not have been more helpful.
Having said that, I still wish that as a design decision, rvm didn't override cd.
It would be somewhat cool if ruby-build knew how to look for an rbenv folder to install rubies into, or if rbenv knew how to drive ruby-build to put rubies in the right directory, but otherwise it's pretty nice.
That's a good idea... ruby-build could provide an `rbenv-install` plugin command for rbenv.
I was just about to go an do this. Has anyone else yet?
ruby-build seems fairly small.
Have you considered just including it inside rbenv's bin directory?
That may decrease the friction and improve the 'git checkout rbenv, add path, and get started' workflow.
That may decrease the friction and improve the 'git checkout rbenv, add path, and get started' workflow.
It is fairly small, but I think part of the idea is to decouple rbenv from how or with what tools you build Rubies. (It might make sense, though, for someone to create and maintain a fork that bundles ruby-build and rbenv.)
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
:~ which bi
bi: aliased to bundle install --path vendor/bundle
(You should only have to run this the first time you bundle.)
You can tell Bundler to install to a relative path by default by putting the following in ~/.bundle/config:
---
BUNDLE_PATH: vendor/bundle
You can use Bundler to isolate your gems locally, or you can use rbenv-gemset:
https://github.com/jamis/rbenv-gemset
https://github.com/jamis/rbenv-gemset
For anyone that grew up outside of using a Bourne Shell (bash, sh, etc) like myself, this appears to be compatible with at least the C shell. A welcome relief, in my opinion.
I just uninstall rvm and install rbenv. It seems to work so far. I'm glad to switch. rvm confused the hell out of me.
I upvote this because RVM caused me more pain than salvation.
I regret the time wasted for RVM. Thanks for this vamsee!
I appreciate RVM and Wayne offers fantastic, other-worldly support. That said, there's always room for alternatives and I'm intrigued by rbenv. The part that gives me pause is the need to run `rbenv rehash` after installing a ruby (not so bad and possibly fixable if the aforementioned change to ruby-build is made) or after installing a gem that has binaries (I predict I will forget to do this a ton).
I could definitely see myself wanting to override `gem` in order to detect binary installations and automatically rehash. At which point, it's not so unobtrusive!
Still interested enough to try it out and see if that is as much of a hassle as I think it will be.
I could definitely see myself wanting to override `gem` in order to detect binary installations and automatically rehash. At which point, it's not so unobtrusive!
Still interested enough to try it out and see if that is as much of a hassle as I think it will be.
Is it production ready? RVM is.
I don't see a pressing need to use RVM in production; when I deploy, I pick a Ruby version and stick with it unless there's a security issue, at which point I pull the updated REE package from Phusion/let Heroku figure it out.
Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
> 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)
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.
Recommending debian-ruby for production use is bordering on physical injury.
The complete lack of a changelog doesn't help either. I never know whether something's going to break in a new release and almost every new release has some little semantic change that borks my system.
I have to use rvm in production because debian/ubuntu install ruby 1.8 and I need 1.9.2 for rails 3. Ruby isn't in the alternatives system (yet - coming soon) so I don't see a better way.
Installing 1.9.2 from source if it is in fact not in the repos is far better then using RVM.
Using RVM anywhere is suboptimal, but using it in production is lunacy.
Using RVM anywhere is suboptimal, but using it in production is lunacy.
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 achieve from my point of view.
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).
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]).
RVM belongs nowhere near production. It exists so that the guys with the macbooks can sync up versions with what is happening in the Linux distro, not the reverse.
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 people.
http://qa.debian.org/popcon.php?package=ruby1.8
http://qa.debian.org/popcon.php?package=ruby1.8
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.
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.
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 overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.
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 overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.
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.
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.
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.
Yet I don't know a single ruby shop who runs with a distro-packaged ruby, even though REE is available as a .deb.
We do - nothing wrong with Debian stable's 1.8.7 and/or 1.9.2.
I do this for a living, and I've used Debian-packaged Ruby wherever I've gone. I haven't experienced issues.
I use the Phusion-provided .debs for REE on Ubuntu.
Count us in. We only use packaged ruby, be that MRI or JRuby.
Why would you not use the same version you develop your code on every day for production?
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.
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.
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.
+1. Many programmers who are not admins tend to install stuff according to their one-time desire and then announce it "production ready". In fact, there's something called "release management" and it's a rather different mindset. Please coders, respect your admins (and vice-versa), or learn to play both roles. Tools like rvm, while cool, are not substitute for this, because they can create an illusion that there's nothing to learn. There is.
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.
RVM is hardly development ready, imho.
Every week I run into problems/confusion with the environment it creates and expects.
I would never put it anywhere near production.
Every week I run into problems/confusion with the environment it creates and expects.
I would never put it anywhere near production.
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.
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.
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.
login as regular user, download some version of ruby, compile for use as logged in user, install rvm, shazzam install any version of ruby you want - all of this only applies to the logged in user and has zero impact on the rest of the system. RVM rules :)
I no longer install ruby at a system level, not needed, only users running ruby stuff need ruby installed and never use distro ruby, creates all sorts of issues...
I no longer install ruby at a system level, not needed, only users running ruby stuff need ruby installed and never use distro ruby, creates all sorts of issues...
The project is only 10 days old (so, no).
It looks promising though, especially as an alternative to RVM in development. I'm keen on installing something that doesn't take over my shell.
I'm not going to lose sight of how awesome RVM is though. It changed the way I develop in Ruby.
It looks promising though, especially as an alternative to RVM in development. I'm keen on installing something that doesn't take over my shell.
I'm not going to lose sight of how awesome RVM is though. It changed the way I develop in Ruby.
I'm guessing rbenv isn't meant for production. As to some of the comments about how you should never use RVM in production, it's complete crap. I've used RVM in production on multiple servers for well over a year. RVM fits perfectly in corporate environments where you have no access to the sudo command.
Where can one by some "production ready"? ;-)
We are software nerds people. It is supposed to be cool to se how others solve problems. It is as simple as that.
With RVM you can change the rubygems version for an installed ruby interpreter. Is something like these possible with rbenv too? i use rubygems -v 1.3.6 for ruby-1.8.7 and rubygems -v 1.8.6 for ruby-1.9.2. I remember i had problems using rubygems 1.8.6 with ruby-1.8.7
Really damn handy feature, especially with the compatibility clusterfuck that has been rubygems > 1.3.6
I've never had any problems with RVM, however with that said I will absolutely check out the code on github and may try this out.
This looks promising because it looks like it will work seamlessly with tmux/screen, something rvm struggles with.
I never had a problem using RVM with tmux.
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)
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]
$ rvm list
rvm rubies
jruby-1.6.3 [ darwin-i386-java ]
=> ree-1.8.7.2001.03 [ x86_64]
Of course that is expected behaviour: tux loads multiple independant shell environments. A change in one will not affect the other. The same holds true for modifying the PATH environment variable, which is how rbenv works. So I'm not sure how you're expecting rbenv to avoid that behaviour.
Good to see competition. RVM's "bug tracker" is the IRC channel...
was this really necessary? i think RVM does a fine job at managing rubies.
rvm is easier to type than rbenv. i know aliases exist but whyyyyy? roarrr