Rbenv with $GEM_HOME?

Ruby
1

I would like to be able to upgrade Ruby minor versions without
reinstalling all my gems but haven’t had much luck so far. Eventually I
stopped using rbenv and installed Ruby 2.1 from source using $GEM_HOME
as my gem location. This worked up to 2.1.2 but, for some reason I still
haven’t fathomed, 2.1.3 and 2.1.4 would not install (OS X 10.8). Is
there any way of making rbenv work with GEM_HOME instead of creating a
new gems folder for every minor Ruby version?

gvim

2

El Tuesday 11 November 2014, gvim escribió:

I would like to be able to upgrade Ruby minor versions without
reinstalling all my gems but haven’t had much luck so far. Eventually I
stopped using rbenv and installed Ruby 2.1 from source using $GEM_HOME
as my gem location. This worked up to 2.1.2 but, for some reason I still
haven’t fathomed, 2.1.3 and 2.1.4 would not install (OS X 10.8). Is
there any way of making rbenv work with GEM_HOME instead of creating a
new gems folder for every minor Ruby version?

I started with Ruby from the system. Added GEM_HOME to the mix, because
I want
a clean separation of what gems I install as a user and what the system
(the
package manager of my Linux distribution) is aware of.

Then I added rbenv to the mix, and I found out that switching ruby’s
with
rbenv was nice. The problem is that the gems were always installed on
GEM_HOME
(of course), but not in all cases were compatible. I had trouble with
one that
uses native code, IIRC. I explored a bit what rbenv was capable of, and
what
the extensions could do, but I think is not there yet. This pull request
hints
in the right direction, but is not there yet:

My solution was to ditch rbenv for now, since I just wanted 2 Ruby
versions:
the one from the system, and a more recent one. The build is trivial. I
configured with --prefix=$HOME/local/ruby-x.y.z and done. When I need
the
locally installed, I unset GEM_HOME (gems will be installed to
$HOME/local/ruby-x.y.z/lib/ruby/gems/, which is fine for me), and either
use
the full path, or I fix the PATH so the version in ~/local has
precedence).

3

On 12/11/2014 06:40, Alejandro E. wrote:

El Tuesday 11 November 2014, gvim escribi??:

I started with Ruby from the system. Added GEM_HOME to the mix, because I want
a clean separation of what gems I install as a user and what the system (the
package manager of my Linux distribution) is aware of.

Then I added rbenv to the mix, and I found out that switching ruby’s with
rbenv was nice. The problem is that the gems were always installed on GEM_HOME

Are you saying you used rbenv and had it install your gems in GEM_HOME?
If so, I’d like to know how you did it as all my use of rbenv resulted
in new gem installations for minor Ruby point updates.

gvim

4

El Wednesday 12 November 2014, gvim escribió:

Are you saying you used rbenv and had it install your gems in GEM_HOME?

If I recall correctly, yes. If you set GEM_HOME is always trying to
install
there, isn’t it?

If so, I’d like to know how you did it as all my use of rbenv resulted
in new gem installations for minor Ruby point updates.

I didn’t do anything special that I know of:

5

On 12/11/2014 17:09, Alejandro E. wrote:

Comment rbenv for now · suy/configs@f0a82e3 · GitHub

My mistake, it seems. I just reinstalled rbenv with GEM_HOME already
defined and I now have what I wanted. I think the problem I ran into was
having installed rbenv originally without defining GEM_HOME and adding
it later. I was also installing gems with rbenv exec gem install <gemname> which may also account for why newly installed gems didn’t
end up in GEM_HOME.

gvim