Background: due to a number of unfortunate choices by the brew team,
that tool is no longer as helpful as it used to be for installing Ruby
or Apache httpd. Shane and Dave Fischer are working through this with
rbenv, a journey that is made more difficult because they don't know how
these parts of of the system fit together.
So, a quick brain dump. First an easy observation: ruby packages are
called gems. Ruby gems may have executables (bundler being an example).
Gems are maintained on a per-minor version of Ruby basis, meaning that
upgrading from 2.3.1 to 2.3.2 doesn't require you to install new gems,
but upgrading to 2.5.1 does.
Running the 'gem env' will tell you everything you need to know about
the paths that are used. In practice, none of that matters. What
matters is that 'gem' command is an executable and at any point in time
is associated with a given version of Ruby. If that version of Ruby is
different than the version that is used by the 'ruby' command or
passenger, then you will experience issues. Issues like not being able
to find the bundler gem when you know darn well that you installed it.
rbenv manages this by creating shells or binstubs: small scripts that
wrap each command. To use rbenv correctly means adding the rbenv
directory to your path. Reading that part of the rbenv documentation is
critical. Get the path right, everything else works. Get the path
wrong, and bad things happen.
Once you have a webserver up and running, whimsy endpoints are helpful.
The first is:
https://whimsy.apache.org/test.cgi?debug
This runs ruby as a CGI script, which is quite different than running
ruby as a passenger/sinatra/rack application. To see the equivalent for
such applications, go to:
https://whimsy.apache.org/racktest/
Obviously, adjust the hostname to match your host. Perhaps 127.0.0.1,
or (if you have configured it in your /etc/hosts and Apache
configuration) whimsy.local.
- Sam Ruby
