5 ms·

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

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 11y ago
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).
- mikekchar 11y ago
  It mostly kicks in when you are a developer that supports 4 or 5 different ruby-on-rails sites, each of which require different versions of ruby. Rails, in particular, seems to be very intolerant of running on different ruby versions, so if you have been less than scrupulous in keeping all your rails apps up to date, you will be juggling different ruby versions. Using Debian "alternatives" is one way of dealing with it, but you also need to be hyper sensitive about the gem versions, so you will be using bundler in most cases. Rbenv, et all, just deals with the complexity so that it is hard to make a mistake. It's not impossible to do it other ways, but it is much harder.
- elliotec 11y ago
  I use Ruby often, not sure if I quite "get it" either, and maybe I don't really understand what you're saying but I think using rbenv is easier than writing a three line shell script to build aliases or symlinks. ```rbenv global 2.3.0```, and you're set.
- lucaspiller 11y ago
  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/chruby/chruby.sh https://github.com/postmodern/chruby/blob/master/share/chrub...
- lobster_johnson 11y ago
  If you run the right interpreter (e.g., ruby-2.1), it will know what paths to load gems and libraries from. So that's not the problem. As others mention, scripts typically just run "ruby" (via shebang or directly), which will pick whatever is the default. Debian/Ubuntu have the "alternatives" system, which is designed to solve this for any kind of program, but it's virtually impossible to use by humans; there's no single command to switch between versions. Fortunately, the ruby-switch package [1] wraps the terrible UI in a single command to switch versions. I highly recommend it. Of course, this switches the version globally. To get per-shell Ruby versions, you will need the other tools mentioned in this thread. [1] https://wiki.debian.org/Ruby https://wiki.debian.org/Ruby
briandear 11y ago
NPM is atrociously bad. Bundler is amazingly good.

saurik 11y ago

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

mikekchar 11y ago
It mostly kicks in when you are a developer that supports 4 or 5 different ruby-on-rails sites, each of which require different versions of ruby. Rails, in particular, seems to be very intolerant of running on different ruby versions, so if you have been less than scrupulous in keeping all your rails apps up to date, you will be juggling different ruby versions. Using Debian "alternatives" is one way of dealing with it, but you also need to be hyper sensitive about the gem versions, so you will be using bundler in most cases. Rbenv, et all, just deals with the complexity so that it is hard to make a mistake. It's not impossible to do it other ways, but it is much harder.
elliotec 11y ago
I use Ruby often, not sure if I quite "get it" either, and maybe I don't really understand what you're saying but I think using rbenv is easier than writing a three line shell script to build aliases or symlinks. ```rbenv global 2.3.0```, and you're set.
lucaspiller 11y ago
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/chruby/chruby.sh https://github.com/postmodern/chruby/blob/master/share/chrub...
lobster_johnson 11y ago
If you run the right interpreter (e.g., ruby-2.1), it will know what paths to load gems and libraries from. So that's not the problem. As others mention, scripts typically just run "ruby" (via shebang or directly), which will pick whatever is the default. Debian/Ubuntu have the "alternatives" system, which is designed to solve this for any kind of program, but it's virtually impossible to use by humans; there's no single command to switch between versions. Fortunately, the ruby-switch package [1] wraps the terrible UI in a single command to switch versions. I highly recommend it. Of course, this switches the version globally. To get per-shell Ruby versions, you will need the other tools mentioned in this thread. [1] https://wiki.debian.org/Ruby https://wiki.debian.org/Ruby

briandear 11y ago

NPM is atrociously bad. Bundler is amazingly good.