You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Sam Ruby <ru...@intertwingly.net> on 2019/04/25 22:37:45 UTC
Primer on Ruby gems
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
Re: Primer on Ruby gems
Posted by Sam Ruby <ru...@intertwingly.net>.
Cool! Consider submitting a pull request against:
https://github.com/apache/whimsy/blob/master/MACOSX.md
- Sam Ruby
On Thu, Apr 25, 2019 at 7:13 PM Dave Fisher <da...@comcast.net> wrote:
>
> Hi Sam,
>
> Thank you so much. I am now seeing Podling Roster pages on my whimsy.local!
>
> Regards,
> Dave
>
> > On Apr 25, 2019, at 3:37 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > 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
>
Re: Primer on Ruby gems
Posted by Dave Fisher <da...@comcast.net>.
Hi Sam,
Thank you so much. I am now seeing Podling Roster pages on my whimsy.local!
Regards,
Dave
> On Apr 25, 2019, at 3:37 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> 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