DEV Community: Moncef Belyamani

How to Install Ruby 2.6.x on macOS 13 (Ventura) and Monterey

Moncef Belyamani — Tue, 21 Feb 2023 19:06:37 +0000

"How can I install Ruby 2.6.x on a Mac M1/M2?" I get asked this question a lot, and I see it often in the various online Ruby hangouts. People try all kinds of things but no one seems to be able to succeed. Some people say to use Rosetta, and others say forget about 2.6 and update your project to 2.7.

The truth is that it is possible to install Ruby 2.6 on an Apple Silicon Mac, and in this article I'll show you 3 different ways to do that. You can skip directly to each solution with the links below, but I highly recommend reading the whole article to better understand how Ruby installation works on a Mac, and why most solutions people try don't work.

Install Ruby 2.6.10 with Ruby on Mac Ultimate
Install Ruby 2.6.10 with Homebrew
Downgrade to version 13.4 of the command line tools (does not work with Ventura)

Do your solutions only work with 2.6.10? I need an older version!

This is another common source of confusion because people don't understand how Ruby versioning works. They get stuck because they think they have to use the version of Ruby that's specified in the project's .ruby-version and/or Gemfile. Instead, it's recommended to update the project to at least the latest patch version (the third digit).

For example, if your project is currently using Ruby 2.6.6, or any version of 2.6 lower than 2.6.10, the first thing I recommend you do is update it to 2.6.10. And then the next thing you want to prioritize is updating it to 2.7.7 because Ruby 2.6 reached end of life in March 2022, which means it has known bugs and security issues that will never be fixed. Note that you can also go straight from 2.6.x to 2.7.7.

This is super important to understand, so please read my guide that explains how and why to upgrade the Ruby version in your project.

How Ruby installation works on a Mac

Some people will tell you that Ruby 2.6 is not compatible with Apple Silicon Macs. Yet, Ventura comes preinstalled with Ruby 2.6.10 on all Macs. That proves that it is possible to install it on Ventura on both Intel and Apple Silicon Macs.

However, this version of Ruby preinstalled by Apple is not meant to be used for development. Read my article that goes over 5 reasons why you shouldn't use the system Ruby on macOS.

Instead, you'll want to use a special tool that can install a separate version of Ruby that doesn't interfere with the one that Apple installed. These tools, known as version managers, can install multiple versions of Ruby at the same time, and let you easily switch between them. The most popular ones are asdf, chruby/ruby-install, frum, rbenv/ruby-build, and rvm.

The problem is that these version managers (when used out of the box with their default settings) fail to install Ruby 2.6.x on any Mac running on macOS Ventura (13.x), and in some cases on the latest version of Monterey (12.6.x) that has version 14 or higher of Apple's command line tools (CLT).

Assuming you have Homebrew installed, you can check which version of the CLT you have by running brew config, and then look towards the bottom for the lines that start with CLT: and/or Xcode:

The reason why some version managers can't install certain versions of Ruby is because they all compile Ruby from scratch, and whether or not the installation succeeds depends on five main factors:

The CLT version
The macOS version
The Mac chip (Intel or Apple Silicon)
How the version manager configured Ruby
Whether or not you have prerequisite tools installed (many version managers don't install them for you)

Each version manager configures Ruby differently, which is why you might be able to install a particular version with ruby-install for example, but not with asdf or rbenv. Note that these version managers allow you to override some or all Ruby configuration settings, but the vast majority of people use the default settings. This makes sense because modifying anything would require deep knowledge of how Ruby configuration and compilation works.

In addition, the way Ruby needs to be configured depends on the Ruby version. However, most version managers use the same settings for all versions. One exception is ruby-build (the tool that both rbenv and asdf use to install Ruby) which uses an appropriate version of OpenSSL depending on the Ruby version. That's not enough in some cases, though, and the fact that ruby-build compiles its own version of OpenSSL has some downsides.

That's why I built Ruby on Mac. It's the result of eleven years of helping thousands of people set up a reliable Ruby dev environment on their Mac. I also continuously spend hundreds of hours researching and testing various Ruby versions on 4 different Macs using all kinds of scenarios. Ruby on Mac guarantees a successful installation of any supported Ruby version on macOS 13 (Ventura), 12 (Monterey), and 11 (Big Sur). For now, that includes 2.6.10 and above with Ultimate, and 2.7.x and above with Prime. I'm working on adding support for super old Ruby versions like 2.3.x, but I need to do more testing.

What about Rosetta?

Some people will tell you they found a solution using Rosetta, but that means one of these two results:

They end up doing all of their dev work with Rosetta, which is a shame not to take full advantage of the Apple Silicon chip.
They try to set up two dev environments — one with Rosetta, and one in native mode — and they inevitably run into all kinds of issues. Then they waste time either trying to fix them or removing everything and starting over from scratch.

The good news is that if you've been using Rosetta to work on a Ruby 2.6.x project, you can use Ruby on Mac's "reset" mode, which will safely back up, then clean up your dev setup in 1 minute, and then you can run it in "normal" mode to reinstall everything from scratch in native mode.

Now that you have a basic understanding of what can cause Ruby installation to fail, let's go over three solutions for installing Ruby 2.6.10 on your Mac, from easiest to most time-consuming:

Install Ruby 2.6.10 with Ruby on Mac Ultimate
Install Ruby 2.6.10 with Homebrew
Downgrade to version 13.4 of the command line tools (doesn't work on Ventura)

Install Ruby 2.6.10 with Ruby on Mac Ultimate

With Ruby on Mac Ultimate, installing Ruby 2.6.10 on Ventura or Monterey is as easy as running this command (after installing Ruby on Mac):

rom install ruby 2.6.10

You don't have to do anything else to configure it, and you don't have to mess with your PATH or shell file to be able to switch to other Ruby versions.

To start using 2.6.10, you'll quit and restart your terminal, then run this command:

chruby 2.6.10

Install Ruby 2.6.10 with Homebrew

Install Homebrew if you haven't already
Install Ruby 2.6.10: brew install ruby@2.6
Follow the instructions for setting your PATH. For example, Homebrew will say something like this:

By default, binaries installed by gem will be placed into:
  /opt/homebrew/lib/ruby/gems/2.6.0/bin

You may want to add this to your PATH.

If you need to have ruby first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/ruby/bin:$PATH"' >> ~/.zshrc

The reason Homebrew is able to install 2.6.10 is because this is a pre-built version of Ruby that was compiled with version 13.3 of the command line tools. However, note that it's not officially supported.

Unless you know what you're doing, in order to use the Homebrew Ruby, you'll need to disable any other version manager you might have used before (such as asdf, chruby, frum, rbenv, or rvm). And you'll only be able to use 2.6.10 with this setup. You won't be able to switch to other versions that you might have installed with another version manager, unless you make changes to your shell file to disable the Homebrew Ruby and turn your version manager setup back on. You'll have to keep doing this each time you want to switch between 2.6.10 and other versions.

This is meant as a temporary solution so that you can run your project with 2.6.10 and then update it to 2.7.7, and then 3.1.3, and so on. Also, note that either way, you'll need to update your project to at least 2.6.10. There's absolutely no reason to use any other version of Ruby 2.6.x. For security reasons, it's recommended to make sure your apps are running the latest version in a series. For 2.6, it's 2.6.10, for 2.7, it's 2.7.7, then 3.0.5, 3.1.3, and 3.2.1.

Downgrade to version 13.4 of the command line tools

This is not possible on macOS Ventura (13.x), so don't waste your time trying. It will probably take you less time to update your project to 2.7.7 than it would to downgrade from Ventura to Monterey.

If you're on macOS Monterey, follow the steps below to download and install version 13.4 of the command line tools. Note that this is not guaranteed to work, depending on which version of Monterey you're running. I had success with macOS 12.1, but some issues with 12.6.

Note that it should never be necessary to download the huge 7GB Xcode app unless you're building macOS and iOS apps. In other words, if you're never going to use the Xcode app itself, all you need are the standalone Command Line Tools.

Download "Command Line Tools for Xcode 13.4".
Install them, but keep the DMG when it asks you if you want to Trash it, just in case you need to install them again.
Check that Homebrew is using the correct CLT with brew config. You should see CLT: 13.4.0.0.1.1651278267. If not, try reinstalling them.
Run brew doctor to make sure everything is fine. If not, follow Homebrew's instructions for fixing issues.
Reinstall all Ruby-related tools with Homebrew:

brew reinstall automake bison gdbm libffi libyaml openssl@1.1 openssl@3 readline

Install Ruby 2.6.10 with your favorite Ruby version manager. If you haven't yet installed a version manager, you can either buy Ruby on Mac, which will set everything up for you in 15 minutes, or spend an hour following my step-by-step guide for installing Ruby on a Mac.

Automate GitHub API Calls With Ruby, Keyboard Maestro, and 1Password CLI

Moncef Belyamani — Wed, 07 Sep 2022 15:38:59 +0000

One of the perks of the "Ultimate" version of Ruby on Mac is access to the private GitHub repo. As a developer — especially one who loves automation — it was tempting to try to completely automate inviting new Ultimate customers to the repo.

To do that would require implementing a custom checkout that captures the customer's GitHub username, so I can then pass it on to the Paddle checkout flow. Paddle unfortunately doesn't support adding custom fields to their checkout.

From there, I would only need to add a few lines of code to my existing small Rails app that receives the Paddle webhook. I'm currently using it to automatically add/update customers in my ConvertKit account, so I can easily segment them based on which product they bought, calculate their lifetime value, auto-populate a field with their upgrade coupon, and other useful things.

After extracting the GitHub username from the Paddle payload, I would use the octokit gem to add the customer as a read-only collaborator to the repo. Something like this:

client = Octokit::Client.new(access_token: github_token)
client.add_collaborator(repo, username, permission: 'pull')

Given that I'm only getting a few orders of Ultimate per week, I thought I would practice the fine art of flintstoning and invite each user manually for now. However, that doesn't mean I have to do it the slow way each time.

When a customer emails me to request access, all I have to do is copy their username from the email they sent me, then I press ⌃-⌥-⌘-A, and it's done!
This automation uses Keyboard Maestro, the GitHub API, and 1Password CLI.

Here's what the Keyboard Maestro macro looks like:

While you can run scripts directly in Keyboard Maestro, I chose to run the script from the project folder in iTerm because the octokit gem is already installed there. Here's what the add_collab.rb file looks like:

require 'octokit'

def repo
  "rubyonmac/rom-ultimate"
end

def github_token
  `op item get "add_collab GH token" --fields label=notesPlain`
end

def client
  @client ||= Octokit::Client.new(access_token: github_token)
end

customer_github_username = ARGV[0]

puts "adding collaborator #{customer_github_username}"
response = client.add_collaborator(repo, customer_github_username, permission: 'pull')
puts "response: #{response}"

And here's the Gemfile:

source "https://rubygems.org"
ruby File.read(".ruby-version").strip
gem "octokit"

If you've read my previous automation guides featuring Keyboard Maestro, you'll recall that it comes with many handy tokens that are placeholders for data that would otherwise require complicated code to fetch. In this case, I'm using the %SystemClipboard% token to pass in the username (that I copied from the customer's email) as an argument to the Ruby script. When you pass an argument to a Ruby script, you can access it via ARGV[0].

For security reasons, I need to provide the Octokit gem with a valid GitHub token associated with my account to be able to make this particular GitHub API call. The way I created this token was by adding a new Personal Access Token to my GitHub account, and giving it the appropriate scopes: admin:org and repo. I also set it to expire after 30 days.

Because I use two Macs at home, I keep all my projects on GitHub so I can easily have the latest code on both computers. However, I gitignore files that contain secrets (like GitHub tokens), even on my private repos. I do this for added security, and also out of habit.

In the past, this would require copying the secret file (such as .envrc if using direnv) from one computer to the other, and then updating it on both computers each time I renew it. It also requires remembering to back up the gitignored file on an external drive if I ever replace my Macs.

But now that I discovered the 1Password CLI, I can get rid of .envrc, and I don't need to worry about copying files back and forth or backing anything up. I can fetch the token from my 1Password account, which is automatically available on both computers.

What I like most about this approach is that I no longer need to have any secrets stored in plain text on my computer (except in 1Password)! I can also safely make this repo public if I wanted to.

So, instead of the usual ENV['GITHUB_TOKEN'], I can fetch the token with the 1Password CLI op tool:

def github_token
  `op item get "add_collab GH token" --fields label=notesPlain`
end

In Ruby, you can run shell commands by surrounding them with backticks. You might also be familiar with the system command, but it doesn't return the output of the command. It returns true if the command succeeds (with a zero exit status). Since I want the actual output of the command, I need the backticks.

As you might guess from the op command, the token is stored in a Secure Note in 1Password called "add_collab GH token". I figured out the full command by reading the documentation for item get, and then running just this command at first:

op item get "add_collab GH token"

which returned something like this:

ID:          some_unique_id
Title:       add_collab GH token
Vault:       Personal
Created:     4 days ago
Updated:     4 days ago by Moncef Belyamani
Favorite:    false
Version:     1
Category:    SECURE_NOTE
Fields:
  notesPlain:    my_github_token

That's how I knew that the label I needed was notesPlain. Here's the full command again:

op item get "add_collab GH token" --fields label=notesPlain

To make this more robust, I could redirect stderr to stdout by adding 2>&1 to the end of the command, then store the result in a variable, and only call the GitHub API if there's no error. Something like this:

def github_token
  token = `op item get "add_collab GH token" --fields label=notesPlain 2>&1`
  if token.include?("ERROR")
    puts "Failed to fetch token from 1Password: #{token}"
    nil
  else
    token
  end
end

def client
  @client ||= Octokit::Client.new(access_token: github_token)
end

if github_token
  puts "adding collaborator #{customer_github_username}"
  response = client.add_collaborator(repo, customer_github_username, permission: 'pull')
  puts "response: #{response}"
end

The reason for redirecting stderr to the output is to be able to read and store the error message. Without the redirection, if there's an error, token will just be an empty string.

Alternatively, I could still use direnv by calling the op command in .envrc, like this:

export GITHUB_TOKEN=`op item get "add_collab GH token" --fields label=notesPlain`

Since there's no secrets in it anymore, I would be able to commit .envrc to the repo. And if there's an error fetching the token, I would see it after running direnv allow. This approach would be handy for projects that depend on secrets being stored in env vars, like the RAILS_MASTER_KEY in Rails apps.

To save even more time, I could automate the process of verifying that the person who is requesting access did indeed buy Ruby on Mac Ultimate. Again, Keyboard Maestro makes this easy with the %MailSender% token.

I would then pass this email address as a second argument to my Ruby script, and then use the ConvertKit API via the convertkit-ruby gem to see if there's an existing entry for that email address, and that the custom field that indicates they purchased Ultimate is filled in.

There you have it. Thanks to Keyboard Maestro, 1Password CLI, the Octokit gem, and a few lines of Ruby, I save about 30 seconds per customer compared to doing everything manually via the GitHub site. With 52 Ultimate customers so far (I just launched the Ultimate version in late July 2022), that's almost 30 minutes saved so far!

If you enjoyed this post and want more free automation ideas and tutorials, sign up for my weekly newsletter.