Hacker News Reader

Comment by jph | Hacker News Reader

Also try the postmodern tools: ruby-install & chruby, which work perfectly in my experience:

https://github.com/postmodern/ruby-install

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.

rbenv doesn't require _any_ special integration to be used from inside Emacs. As long as chruby needs that, it doesn't seem like a good alternative to me.

Chruby's so small that you might as well rewrite it in elisp.

As a ruby outsider, I wonder do those have any practical effects on how you write/run programs? Do they save time or prevent bugs? Why is versioning such a huge problem in ruby?

They are tools for managing multiple installed versions of a programming language. When developing software, we often specify dependencies using version numbers, which indicate the version of the language or library that should be used when running the software. Running the software with the specified language runtime or library version ensures that the expected features of that library or language runtime are available and also helps avoid unexpected issues related to differences in the environments, including different developer's local systems as well as remote server environments.

In the case of a programming language runtime, if you have one project that's configured to use version 2.2.4 of a language and another that's configured to use version 2.1.0, these tools provide an easy way to install and switch between the two versions.

This is not unique to Ruby, and similar projects exist for other languages. For example, nvm (https://github.com/creationix/nvm) and n (https://github.com/tj/n) provide something similar for Node (JavaScript), gvm (https://github.com/moovweb/gvm) for Go, and multirust (https://github.com/brson/multirust) for Rust.

I've dabbled a little bit in Ruby, and I found this to be a much larger problem than it is with Python. Most systems have python 2 and/or python 3. Beyond that, I've rarely need to worry very much about which Python version I have. But for every new Ruby application I install on my machine, I'm messing around with rvm.

Is it truly a difference between the languages release strategy or is this just my perception because of limited experience with Ruby? I found it to be a huge pain in the ass.

It's annoying for sure, and I like that we don't need it in Python land. But, in situations when we do want to target multiple Python versions, an identical approach using pyenv works well. I've come to appreciate it more.

It's not really a problem per say. It's just taste really. There are multiple good options for managing ruby versions and environments. (as well as other languages like Phython, see pyenv). I don't necessarily switch to ruby versions between projects or with frequency. That being said, ruby is in active development and with new versions there are many improvements to performance and security. So developers like to try the latest and test out their apps, libraries and frameworks.

I'm sorry I wasn't more clear, I'm wondering why there seems to be a war of sorts between which version manager to use for ruby. Are the differences between rvm, rbenv, chruby, ruby-install practical or purely ideological? There doesn't seem to be this kind of disagreement over which version manager is best in other languages, just ruby, why is that?

rvm hooks into the cd command which has caused people nightmare-level debugging marathons. rbenv's key feature was that it did not do that and uses a shim instead.

To add a little more to the history, I made the switch from rvm to rbenv when rvm broke under me (I can't remember now whether it was `cd`-hooking or rubygems-bundler which broke the camel's back). I made the switch from rbenv to chruby when rbenv's shims broke. Chruby does so little that there's almost nothing to break, so I've stayed there.

There's a lot of reasons, but the most significant one is that Ruby successfully and recently made a compatibility break between versions (1.8 and 1.9), which made the ability to run multiple Ruby versions on a single machine extremely important to a large group of people. Toss in alternate implementations like JRuby and Rubinius and it's almost indispensable.

The Ruby dev team tends to prefer encouraging the community to implement competing solutions rather than adopting any of them as official. Ruby devs in general tend to be members of the "there is more than one way to do it" camp.

There isn't really much of a "war". The different version managers came to an agreement on certain things like the format of .ruby-version files, so at this point it's a personal choice akin to which text editor you use.

Libraries that work for an older version of ruby won't always be forward compatible. So if you're working in many projects you can't simply use the latest version of ruby. Then you have things like Jruby which is incompatible with some of the libraries designed for MRI. So, being able to segregate rubies is essential.

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

Rbenv is much smaller and only does ruby version changes and installations with the ruby install add on. rvm is bigger and has more features but is a bigger pain to use in my experience.

Also the whole Gemset thing is basically redundant now Bundler has become the standard way of locking dependencies (Gems).

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".

rvm was perfectly happy to install Ruby 2.3.0 for me this morning, upgrading me from 2.2.4, which is what I was using until last night.

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

The problem with rvm was always that it tried to do too much. With a tool like that, as long as it's working, you won't see the downside. When it breaks, it breaks in complicated, hard-to-debug ways. If you're saying it's reliable for you, that's great. That wasn't my experience.

Huge fan of these, been using them basically as long as they existed. They work well and are significantly simpler.

If you're missing niceties like gemsets around this, there are various companion projects to provide bells and whistles. I've written a couple myself:

https://github.com/regularfry/gemsh https://github.com/regularfry/rv

The wonderful thing is that these projects are so small and simple that writing your own tooling to interface with them feels quicker and easier than evaluating someone else's code...

Quick question: do you still need gemsets if you use Bundler? And why would you prefer using one instead of the other?

Gemsets are redundant when you use Bundler. Your second question will boil down to opinion but Bundler has been extremely solid in my experience. The feature set is huge and the work ethic of the core team is commendable.

I still use isolated $GEM_HOME directories for each project on my dev machine, and don't rely on bundler to separate installations on production machines.

In my mind, bundler was never really needed for that - it was a complexity step further than was required - so I never set myself up to rely on it, instead relying on a simpler mechanism which doesn't need runtime tooling support. As a result, I never have to run `bundle exec`. How much you might prefer this will probably be more dependent on how much you appreciate simplicity.

chruby didn’t work with fish last time I checked. Any idea if it does now?

Fairly well! https://github.com/JeanMertz/chruby-fish

Reply on news.ycombinator.com