Developing on a Mac – Part II – Rails

I wrote Part I of this series to provide a foundation upon which to build a collection of minimal guides to developing software on a Mac. In this post let’s look at what needs to be installed on your Mac for developing a Rails application.

A Ruby Version Manager (But Not the One You Think)

Ruby language development moves at a fairly decent pace, and there was a time when it seemed like new versions of Ruby came out several times a year. In addition to that there are, or were, several Ruby flavors:

• Ruby Enterprise Edition (now EOL)
• Rubinius (appears defunct)
• JRuby

And, of course, there is just “Ruby”. Keep in mind that the Ruby language specification is open and anyone can develop an interpreter. This, coupled with the push to build high-performance interpreters for support applications such as a <href=”https://twitter.com”>Twitter or Airbnb led to a dizzying array of options, particularly in the early 2010s.

There was a time when I would have recommended RVM to manage all of this. Unfortunately RVM suffers from the desire to do way too much, and the last straw for me was when it decided to install its own copy of Homebrew, and to add insult to injury, in the wrong location.

Instead, we’re going to use ruby-install and chruby instead with Homebrew:

Take care to read the instructions after the install of chruby:

Now, let’s install a Ruby:

You’re going to see a lot stuff downloaded, configured, compiled, and installed. This is why we wrote the original post about installing the very basic tools needed to begin development on a Mac.

If everything compiles successfully you’ll see >>> Successfully installed ruby 3.0.4 into /Users//.rubies/ruby-3.0.4 (or something similar depending upon the exact Ruby version). Yet, if you do a which ruby you may see /usr/bin/ruby which is still the system default.

Here is where chruby comes to our aid:

# chruby
ruby-3.0.4

Note: You may need to reload your ~/.zshrc after compiling a new Ruby for chruby to see it.

So let’s switch to ruby-3.0.4:

You might also be wondering what the -- --enable-shared is about. Check out this post.

A Word about OpenSSL

You’ll encounter OpenSSL and it’s headers and libraries over and over (and over) again when doing almost any type of software development, particularly development involving making TLS or HTTPS connections. OpenSSL is open-source software and not included by default in many environments, but so much depends on it. To make matters worse, there are now two versions: OpenSSL 1.1 and OpenSSL 3.0. Don’t get discouraged when you start doing battle with OpenSSL.

gem and bundle

Two other must-have tools for doing development with Ruby are gem and bundler. In version 3.0.4 of Ruby both are these are present, so let’s create a basic Sinatra app!

Open the Gemfile and edit it to look like:

Then type bundle install. You’ll notice the last line:

And looking at the nokogiri gem:

Now, this is a fine point, but one that needs to be made: for our basic_sinatra_app project we installed gems in the “global” gem directory. Global is in quotes here, because it’s not global to the system, only to the user, and only to the specific version of Ruby.

To prove this to yourself, try this:

Here is where things typically go afoul, and that’s a developer’s machine will often have a number of different installations of Rubies, gems, and so on. It is easy to allow these environments to proliferate to the point you don’t know what’s installed where, or which version of Ruby you needed for the latest app you’re building.

On to Rails

We’re going to make a disclaimer here, and that is we’re using Rails 7. Why the disclaimer? With Rails 7.0 there has been a move away from dependencies on tools such as npm that make the installation and use out of the box much easier. Don’t worry, npm will be covered in the So You Want to Develop on NodeJS part of the series.

Edit your Gemfile to look like this:

and bundle install.

rails is now at /Users/joe/.gem/ruby/3.0.4/gems/rails-7.0.4. Oh, if that were the only step.

Typing bundle exec rails new . and you’ll find that the environment wants to overwrite the Gemfile, and that’s okay since we just created it. But, a Gemfile that was 6 lines is now 72 lines. There’s a lot there, but, if all works properly:

Cleaning Up

In this post we installed two tools: ruby-install and chruby. In the process some additional packages were installed by Homebrew. How could we go about uninstalling everything? Well, good luck with that, and its that very problem that makes things difficult at times, or rather, more complicated than they need to be. At a minimum though we can easily delete the ~/.rubies directory that ruby-install populated, which in turn will remove any installed gems.

The Mac I’m using to write these posts I’ve deliberately tried to “keep clean” – after Part II I now have:

Much of these were installed to help build Ruby itself, e.g., autoconf, automake, bison, and so on. xz is there to decompress the Ruby source “tarballs”.

You can see, though, that while it doesn’t take much to get started building a Rails application, we built upon the first post of obtaining the command line developer tools, Homebrew, and so on. All software development, not just on the Mac, is like this. What starts as one install leads to another leads to eight more.

Until next time.