
Rbenv 1.0.0 - nixpulvis
https://github.com/rbenv/rbenv/releases/tag/v1.0.0
======
jph
Also try the postmodern tools: ruby-install & chruby, which work perfectly in
my experience:

[https://github.com/postmodern/ruby-
install](https://github.com/postmodern/ruby-install)

[https://github.com/postmodern/chruby](https://github.com/postmodern/chruby)

~~~
sdegutis
Yep. Moved from `rvm` to `rbenv` when it came out, but didn't realize how much
magic it _still did_. Switched to `chruby` when it came out, was much nicer
experience overall, and faster too. Just wish the Emacs package for chruby was
written a little less ad-hoc.

~~~
NatW
I've been perfectly content using RVM [https://rvm.io/](https://rvm.io/) \-
with all the functionality I need, and reliability, too. What am I missing out
on?

~~~
technion
I fell on rvm because it seems to be the "default" recommendation. I don't see
a need to use something "better" if the raw tool does the job perfectly.

I do get annoyed that "rvm list known" tends to only show old versions. For
example, it suggests it can install ruby-2.2.1, but I'm fully aware 2.2.4 is
available, as is ruby 2.3 now. And for me at least, this problem is consistent
after applying the standard advice of "get the latest rvm".

~~~
mwpmaybe
rvm "stable" hasn't been updated in quite a while, last time I checked. you
need to install the "dev" version.

------
pbreit
I don't get why stuff like this isn't a solved problem and there's one
solution that most people use.

~~~
twblalock
As a Java developer who used to be a Ruby developer, I can't believe how
poorly dependency versioning (and just general Ruby versioning) works. It
should be simple to have multiple versions of libraries coexisting on a
system. Maven can do it fairly easily.

RVM and rbenv seem like hacky solutions to a problem that is easily solved by
specifying dependency versions in your project.

~~~
lobster_johnson
You _can_ have multiple versions of libraries (gems) installed at the same
time. Ruby is no worse than Java here. You can easily have multiple concurrent
versions of Ruby, too. What rbenv etc do is make it easy to switch between
Ruby versions and keep them separate. Bundler is not a hack, and is better
than what is offered by some other solutions (pip, NPM).

~~~
saurik
As someone who clearly doesn't use Ruby often enough to "get it", I don't
understand this problem: I have multiple major versions of Ruby installed on
my server from Ubuntu via APT, and I don't need to "switch" between them...
they are just versions in their install names like all the other versioned
interpreters I install. If I want some kind of "default" build of Ruby, that
seems like it would be solved with nothing more than a three line shell script
to build either aliases or symlinks (and I think Ubuntu already has a way to
do this using diversions).

~~~
lucaspiller
As Ruby is an interpreter most executables just have "#!/usr/bin/env ruby" at
the top of the file. If you have multiple versions of Ruby, this may or may
not pick up the correct version you have installed. Historically the
interpreter has made quite a few breaking changes, didn't follow semantic
versioning and didn't care about backwards compatibility. What these tools do
is alter the environment so that you can 'lock' specific versions of the
interpreter.

The same problem also occurs with libraries, which may also have their own
executables, so these tools have tried to solve both problems - which is
slightly more complicated than a three line shell script. Bundler has become
the standard way of managing libraries, so now something like chruby[0] can be
used to do pretty much what you said for the interpreter alone. Of course the
other tools (that do a lot more) still have their historical followers...

If you are wondering why you need to support multiple versions, these tools
are mainly for use in development environments where you will probably have to
support legacy software that is no longer actively maintained.

[0]
[https://github.com/postmodern/chruby/blob/master/share/chrub...](https://github.com/postmodern/chruby/blob/master/share/chruby/chruby.sh)

------
sandstrom
Another excellent tool for the same problem is chruby[1]. I found it simpler
(in a good way) than rbenv.

[1]
[https://github.com/postmodern/chruby](https://github.com/postmodern/chruby)

------
amorphid
I love Rbenv. Super simple, and it just works.

~~~
mud_dauber
I wish I had the same good experience. Getting things running on Ubuntu 14.04
LTS is an unresolved hairball for me.
[http://stackoverflow.com/questions/23155289/rbenv-build-
fail...](http://stackoverflow.com/questions/23155289/rbenv-build-failed-on-
ubuntu-14-04/23155490#23155490)

------
dbpokorny
I haven't used it, but second hand I've heard that the Python version of this
concept is "virtualenv".

Edit: I probably shouldn't be surprised to learn that second hand information
I picked up six years ago at PyCon is out of date...

~~~
Osmose
Not quite. The Python equivalent is Pyenv:
[https://github.com/yyuu/pyenv](https://github.com/yyuu/pyenv)

~~~
outtwre
I'm a relatively experienced python developer and have never even installed
pyenv.

Whereas with Ruby, I can't seem to get much working without it.

~~~
dham
You can take a fresh install of MacOSX and do anything with Ruby. Only issue
is you need to install some gems using sudo. Same thing with using system
python. You don't need rbenv by any means. In fact our designer has no problem
getting our rails site running and making styling edits.

Hard to say the same with installing Python 3 on MacOSX and getting virtualenv
running, which in my experience hasn't been so easy.

How would you work on a project that uses 3.2, then another that uses the
latest features from 3.5, without pyenv?

~~~
powersurge360
I have a tendency to install one of python 2.x and one of python 3.x and then
use the --python flag to set the particular python I want my project to run
against.

At that point it should work invisibly in the virtualenv.

Unlike ruby, point releases don't often make sweeping breaking changes so it
is often enough to say 'this is python 3 code' or 'this is python 2 > 2.5'
code, so the granularity of something like pyenv is mostly unnecessary, imo.

~~~
dham
That's the way I worked at my last job with Python. I filed for brain fuckery
bankruptcy after trying to get pyenv and pyenv virtualevnwrapper set up.

You can't say this is Python 3 code or Python 2 code. That's completely false.
If someone used latest features from Python 3.5 that wouldn't work on 3.4.

Also, I haven't had any issues upgrading point releases in Ruby(since 2.0).
Point releases do not make sweeping changes by any means. You maybe talking
about the weird 1.8 to 1.9.3 thing.

------
davexunit
Rbenv and all other such tools are narrow, weak solutions for a general
problem: Using multiple versions of a piece of software on the same machine
without collision. Projects like Nix and GNU Guix solve this generally without
needing a new special package manager for each thing you want more than 1
version of.

~~~
briandear
How is Rbenv weak? It does exactly what is needed.

~~~
regularfry
Because it only tackles a single language.

