Rbenv, an unobtrusive rvm replacement
github.com
github.com
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.
If you're wondering "why would I use this instead of rvm?" be sure to read the readme: https://github.com/sstephenson/rbenv#readme
I've never liked how RVM overrides shell commands.
I am glad to see a project that should restore some of my sanity. Good work.
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.
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.
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's plum easy and works out of the box. You're just looking for something to be angry about.
Managing multiple versions of Ruby and all the gems is very easy manually.
RVM is a buggy collection of extremely fragile and dangerous scripts.
ruby==ruby 1.8.7 ruby9==ruby 1.9.2 jruby== jruby 1.6 jruby5==jruby 1.5
Yeah, real tough.
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 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 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.
That may decrease the friction and improve the 'git checkout rbenv, add path, and get started' workflow.
:~ which bi
bi: aliased to bundle install --path vendor/bundle
---
BUNDLE_PATH: vendor/bundle
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.
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.
Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
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)
Recommending debian-ruby for production use is bordering on physical injury.
That's a pretty inflammatory, unsubstantiated opinion. Any reason?
And also that RVM is a development tool, and the overhead it adds to production is silly.
Using RVM anywhere is suboptimal, but using it in production is lunacy.
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.
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.
Yet I don't know a single ruby shop who runs with a distro-packaged ruby, even though REE is available as a .deb.
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.
In my experience, the version of Ruby shipping in most Linux distros and package systems is outdated or less than ideal for production use.
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 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...
Every week I run into problems/confusion with the environment it creates and expects.
I would never put it anywhere near production.
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]