1

I'm not a Ruby user per se, but have it on my system because I use it (so far) for just two things (that I'm aware of):

I'd like to keep both of those current, but I'm confused right off the block by what version of Ruby I'm even using.

When I ask Homebrew I get:

$ brew --config
#...
Homebrew Ruby: 2.0.0-p648
#...
Ruby: /usr/local/bin/ruby => /usr/local/Cellar/ruby/2.4.1_1/bin/ruby
#...

but when I ask my system I get:

$ which -a ruby
/usr/local/bin/ruby
/usr/bin/ruby

$ /usr/local/bin/ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]

$ /usr/bin/ruby --version
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

$ ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]

Why does the "system" Ruby that Homebrew sees not agree with the version that my system uses at the prompt? How do I keep all this up-to-date? Specifically, how do I keep up-to-date

  1. the version of Ruby used by Homebrew
  2. the version used at the prompt, and
  3. my Travis CI tools (and the version of Ruby it uses)?
orome
  • 45,163
  • 57
  • 202
  • 418
  • I don't use either Brew or Travis (I manage Ruby with rbenv) but your system Ruby is 2.0.0, and resides in /usr. You have Ruby 2.2.3 in /usr/local (which is a softlink from somewhere else); /usr/local/bin appears to be first on your PATH. That is, the output from Brew and the shell seem to agree. Be clear when you ask about Ruby "at your prompt", as I see two different Ruby versions "at your prompt". Perhaps you mean "found first on the PATH"? –  Oct 31 '15 at 13:14
  • @jdv: Correct, I mean the one I get with just `ruby`. What this boils down to is (I gather), where the Travis CLI is getting installed and what `--user` and `--system` mean. – orome Oct 31 '15 at 13:16
  • Either the Travis CI tool modifies your environment directly, or you just have /usr/local/bin on your PATH already. `--system` almost certainly means the OS X system Ruby (which really cannot be _easily_ changed now in El Capitan). Assuming these params are arguments to "Travis CI", it probably provides a way to turn on and off the installed Ruby versions on an environment-by-environment way. Furthering the assumption, I suspect the output can be used as input to shell variables like PATH. –  Oct 31 '15 at 13:23
  • Oh, I see. `--system`, et al, are options for Homebrew. Somehow it attempts to update the "system" Ruby, which is _essentially_ has: by installing another version in /usr/local and changing the environment so just typing in Ruby gets you the updated version. –  Oct 31 '15 at 13:28
  • @jdv: That makes sense. So `--system` is probably not a concern (or even relevant). That order for PATH is correct (for a brewed system), and I assume everything I do will use my (newer) Ruby. *But* — what threw me was that Homebrew listed the system Ruby at all. I'm not sure how that's relevant to it or anything else. – orome Oct 31 '15 at 13:28
  • Yeah, Homebrew should not (and in later releases can not) actually update the system Ruby. But it _can_ install later versions in parallel and tweak the environment so that, from your perspective, the default system Ruby is this new version. The only gotcha might be if you run a different shell that somehow does not get this new environment. –  Oct 31 '15 at 13:35
  • 1
    I will give signal boost to "rbenv" again, as it gives you a lot of control over the exact version of the Ruby used in any particular environment, and allows you to install multiple versions of Ruby (including some of the custom versions) in parallel, and select the version you want on the fly. That is, it decouples the installation of Ruby versions from the package manager you use completely. Which for development on OS X I prefer. Maintaining development environments is not something Fink, brew or even apt on Linux do particularly well (IMO). –  Oct 31 '15 at 13:38
  • Last comment, I promise! This might be a duplicate of http://stackoverflow.com/questions/12287882/installing-ruby-with-homebrew (and see a dissenting view of rbenv there.) –  Oct 31 '15 at 13:44

1 Answers1

1

It's possible to have multiple instances of a language installed on a system. By default the ruby executable will be found in /usr/bin/ruby. That version will be used by system-installed Ruby-centric scripts. We can use that, but we shouldn't alter/update/delete it because those tools would break, possibly with spectacular results.

If the user decides to install another version, perhaps because it's more recent, and it's for their use, not for the system's, it'll go into /usr/local/bin/ruby. "local" implies it's for the "local" user's use, not for the system's use.

Our PATH environment variable defines the search path to find things. Typically it'll have "/usr/local/bin:/usr/bin" so that the OS will search in the "local" repository of executables before it'll look in the "system" repository. That allows us to add overrides to commands if we want, again by putting them in the /usr/local/bin directory. Tools that need the originals still know to look in /usr/bin.

The downside to this is that we're only able to have two versions of ruby. To fix that we'd end up tacking on version numbers, like ruby193 or ruby2.2 to multiple instances in /usr/local/bin and then write scripts with #! lines pointing to the appropriate version. But, inevitably we'd mess up, type the wrong "ruby" and break something.

So, some enterprising, really-smart, people figured out we could manipulate our PATH setting, store our Rubies in a different location, typically our home directory, and then write code that can manage which version we want to use. RVM and rbenv are two such tools commonly used in the Ruby world to handle this. I've used them both and they work extremely well.

I'd recommend removing the Homebrew installed instance of Ruby, install either RVM or rbenv, and then allow that "sandbox manager" to handle your Rubies. Your system Ruby needs to stay as it is as you probably want to avoid finding out that it was sacrosanct the hard way.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
  • I was with you until the recommendation to remove the Homebrew installed instance of Ruby. For me that's backwards. I think Homebrew requires it, no? Until I installed the Travis CI CLT, the only reason I had Ruby (and the only thing it was used for) was Homebrew. – orome Oct 31 '15 at 16:27
  • You're on a Mac OS system since you're using Homebrew. Apple installs Ruby for their use in /usr/bin for built-in management scripts and tools. Homebrew is a tool to install "user local" code not provided by Apple. RVM and rbenv are much better tools for handling Ruby than Homebrew, so use it for installing non-Ruby things, and use one of the two sandbox managers for what they're best at. Homebrew *might* install its own instance. If so, let it worry about that version being up to date. If you're not programming let Apple worry about their version. – the Tin Man Oct 31 '15 at 16:29
  • Yes, but leave it alone — don't "remove it" for sure! – orome Oct 31 '15 at 19:02
  • Don't remove Apple's installation of Ruby in /usr/bin. Versions of Ruby installed by an application are owned, and maintenance of it is done, by that application's developers. Any other user-installed version is fair game. – the Tin Man Oct 31 '15 at 20:26
  • I wasn't suggesting that (it can't be done in El Cap anyway), but was reacting to "I'd recommend removing the Homebrew installed instance of Ruby...". – orome Oct 31 '15 at 20:40
  • 1
    @raxacoricofallapatorius you'll find that most Ruby devs use RVM or rbenv to manage their Ruby installation, so yes, it makes sense to remove the Homebrew-installed Ruby (not the system Ruby). This becomes especially important if you decide to install multiple versions of Ruby side by side. – zetetic Nov 05 '15 at 00:58
  • @zetetic: Can I use RVM as part of a Homebrew Ruby setup (they way I can use pip with Homebrew Python)? – orome Nov 05 '15 at 01:16
  • You can but why? RVM or rbenv are much better at managing Ruby installations and very nicely handle installing it. – the Tin Man Nov 05 '15 at 01:24
  • @theTinMan: Homebrew and pip work together just fine and with that setup I use pip to manage my Python installation. Are you saying that the relationship between Ruby and RVM are different? That using Homebrew will get in the way? – orome Nov 05 '15 at 12:37
  • pip works without Homebrew. It's part of Python, not Homebrew. pyenv is the Python corollary to rbenv, and works great, allowing you to manage and use multiple Pythons, just as rbenv and RVM allow use of multiple Rubies. Homebrew is useful, but it's not designed to do what RVM, rbenv or pyenv do. That is why we've repeatedly recommended using them. If you don't want to, don't, but developers use them because they work very well and help us manage our environments. – the Tin Man Nov 05 '15 at 16:09