Thoughts on chruby?

[trans]

Have you looked at chruby by postmodern?

I was wondering what your thoughts are on it and how it compares to ry.

[jneen]

I haven't looked at it too much, but it looks like it also tries to be minimal. It's implemented as a shell function, so it can directly modify your environment (unlike ry, which is implemented in shell as a single executable). This makes it shell-dependent, which is usually OK for most people. It also seems to require sudo, or chowning your /usr/local directory, which I consider a Bad Idea.

But it seems to work well for a lot of folks :). Were you curious about anything else specifically?

[eregon]

I wanted to discuss this as well to know your thoughts.

The idea of being a shell function and using PATH has the nice property to be able to rehash and causes less trouble than changing a symlink (across terminals which can be badly hashed) but it is also less robust (it messes with the environment) and of course does not modify globally the ruby version (in many cases I find it useful but in some other cases not, having both abilities would be nice).

I tried chruby, but it did not stay a day. First, it completely messes things if you happen to have two rubies with the same RUBY_VERSION and engine, or one which does not support the introspection code to set the gem location. Forcing gem location does not seem good or minimal to me and it just brought segfaults as I had two rubies 2.0. That introspection makes ruby switching not fast for jruby and like, and installs a very dangerous environment if that code fails. It is also pretty painful to use existing gem prefix.

Rubinius definitely needs some trick to have its gem binaries in path. This might be done by the version manager, even if not ideal. I think I'll have a pull request for that soon.

[jneen]

It'd be easy enough to modify ry to optionally be a shell function, as
long as it was still usable without that. By default you just symlink
the current directory and everything works out, as long as you don't
need multiple rubies running concurrently. Otherwise, ry exec works
just fine for starting servers and such.

chruby also seems to have a test setup with Vagrant. Having tests for
ry would be awesome, but I'm not sure how to set that up.

On 01/18, Benoit Daloze wrote:

I wanted to discuss this as well to know your thoughts.

The idea of being a shell function and using PATH has the nice property to be able to rehash and causes less trouble than changing a symlink (across terminals which can be badly hashed) but it is also less robust (it messes with the environment) and of course does not modify globally the ruby version (in many cases I find it useful but in some other cases not, having both abilities would be nice).

I tried chruby, but it did not stay a day. First, it completely messes things if you happen to have two rubies with the same RUBY_VERSION and engine, or one which does not support the introspection code to set the gem location. Forcing gem location does not seem good or minimal to me and it just brought segfaults as I had two rubies 2.0. That introspection makes ruby switching not fast for jruby and like, and installs a very dangerous environment if that code fails. It is also pretty painful to use existing gem prefix.

Rubinius definitely needs some trick to have its gem binaries in path. This might be done by the version manager, even if not ideal. I think I'll have a pull request for that soon.

---

Reply to this email directly or view it on GitHub:
#22 (comment)

[terlar]

I also still prefer ry, I have tried out all kind of different stuff. But none are as lightweight with the ability to just set the PATH without having to run any shell-scripts. Especially if you are using some other shell (fish-shell in my case) that is not POSIX compatible.

I'm running multiple rubies at the same time, but only in pow right now, where I'm overriding the PATH in the .powenv with corresponding version.

[trans]

I'd be very interesting in seeing a comprehensive analysis of both solutions, how each works and the consequences of those differences. I am torn between the two, but don't have much to go in so far as making a choice either way.

[eregon]

Quick thought: for servers, it seems changing the ruby globally is not suitable, so chruby might better fit that scenario.

[gretel]

@eregon i dont agree, as server isn't a term that defines any requirements. as @jneen states, chruby may use sudo which i consider to be a worse idea in comparison to hava a global environment setting a single ruby version to use.

[jneen]

For production deployment, I generally recommend going with raw ruby-build and setting $PATH manually.

[gretel]

@jneen, agreed. i has servers requiring a multi-rubies environment, so using ansible with ry to my pleasure as i don't have much dependenices to resolve.
while ruby-build works fine i just had ruby-install --no-install-deps ruby 2.1 to recover from a homebrew meltdown... always good to have a choice 🌳