Gems shared between patch-level Ruby versions.

[pda]

This issue is a discussion point to round up information regarding the way chruby's use of ~/.rubies/ and ~/.gem/ causes different Ruby patch-levels (e.g. 2.0.0-p0, 2.0.0-p195, 2.0.0-p247) to share gems installed in ~/.gem/ruby/2.0.0.

It may be a non-issue (and quite possibly not a chruby-specific issue), so this issue can be closed, but it could still be useful as an information point.

In certain cases, gems are installed like this:

pda@paulbook ~ ⸩ which pry
/Users/pda/.gem/ruby/2.0.0/bin/pry
pda@paulbook ~ ⸩ head -n1 `which pry`
#!/Users/pda/.rubies/ruby-2.0.0-p195/bin/ruby

Note that the shebang points specificaly at the ruby-2.0.0-p195 which was active when the gem was installed.

In this case, I believe RubyGems 2.0.2 was used to initially install the gem.

This mean that even when the newer ruby-2.0.0-p247 is selected, running pry will use the older ruby-2.0.0-p195:

pda@paulbookpro ~ ⸩ ruby -e 'puts RUBY_PATCHLEVEL'
247
pda@paulbookpro ~ ⸩ pry -e 'puts RUBY_PATCHLEVEL; exit'
195

This can be resolved by running gem pristine with the newer ruby-2.0.0-p247 active:

pda@paulbookpro ~ ⸩ pry -e 'puts RUBY_PATCHLEVEL; exit'
195
pda@paulbookpro ~ ⸩ gem --version
2.0.3
pda@paulbookpro ~ ⸩ gem pristine pry
Restoring gems to pristine condition...
Restored pry-0.9.12.2
pda@paulbookpro ~ ⸩ pry -e 'puts RUBY_PATCHLEVEL; exit'
247
pda@paulbookpro ~ ⸩ head -n1 `which pry`
#!/Users/pda/.rubies/ruby-2.0.0-p247/bin/ruby

The gem pristine --all and perhaps gem pristine --all --only-executables are useful here.

I believe there was some speculation that RubyGems 2.0.3 installs with #!/usr/bin/env ruby in bin files, but I'm not seeing this:

pda@paulbookpro ~ ⸩ gem --version
2.0.3
pda@paulbookpro ~ ⸩ gem install pry
Fetching: pry-0.9.12.2.gem (100%)
Successfully installed pry-0.9.12.2
1 gem installed
pda@paulbookpro ~ ⸩ head -n1 `which pry`
#!/Users/pda/.rubies/ruby-2.0.0-p247/bin/ruby

[drbrain]

From just a glance, for chruby, the gems should be installed with --env-shebang

[pda]

Hmm. I wonder if ruby-install or chruby can be made to install/configure/run RubyGems such that --env-shebang is used by default?

It's unlikely users will ever manually use that flag when installing gems, especially when they seemingly work without it.

[pda]

PS: --env-shebang does the job:

pda@paulbookpro ~ ⸩ gem install pry --env-shebang
Fetching: pry-0.9.12.2.gem (100%)
Successfully installed pry-0.9.12.2
1 gem installed

pda@paulbookpro ~ ⸩ head -n1 `which pry`
#!/usr/bin/env ruby

My optimistic first attempt didn't:

pda@paulbookpro ~ ⸩ gem pristine pry --env-shebang
ERROR:  While executing gem ... (OptionParser::InvalidOption)
    invalid option: --env-shebang

[drbrain]

Can you open a feature request on rubygems/rubygems for gem pristine --env-shebang? That seems like a nice-to-have.

[postmodern]

I will consider recommending users add gem: --env-shebang to ~/.gemrc.

[pda]

Adding --env-shebang to the existing install: and update: lines in my ~/.gemrc seems to have done the job for me. I've never been sure if that's exactly equivalent to gem: --env-shebang…

install: --no-rdoc --no-ri --env-shebang
update: --no-rdoc --no-ri --env-shebang

It certainly seems sensible for chruby users to be using --env-shebang.

[postmodern]

Closing this since it's an artifact of rubygems.

[fesplugas]

Had the same problem when upgrading Ruby 2.1.0-preview2 to 2.1.0. The --env-shebang option is sensible for chruby users.

gem: --no-rdoc --no-ri --env-shebang

[jrochkind]

I just ran into this too reported separately at #300.

I understand you consider this a... feature? bug? in rubygems, and not chruby's issue. But it seems like it's something you would not run into unless using chruby, probably will run into when using chruby, and kind of poses a problem for using chruby. No?

It is making me reconsider my use of chruby, if this is something you know will happen to people when using chruby, but don't think anything needs to be done about it.

[jrafanie]

@jrochkind Note, this is not an issue with ruby 2.1 newer since they moved to semantic versioning.

ls -1 ~/.gem/ruby/
1.9.3
2.0.0
2.1.4
2.1.5

Note: 2.1.4, 2.1.5 ruby binary will always be installed to the same place.

This is only an issue with 2.0.0, 1.9.3 and older versions since they re-release 2.0.0 with new patchlevels.

I'd rather chruby not add temporary workarounds for issues with ruby/rubygems.

Perhaps @postmodern can add a "label" for common issues like this and a link to issues with this label can be put on the landing (README) so users can go right there to find things like this. Then, we as a community of users can request an issue/PR be labeled in this way.

[jrochkind]

I think it's chruby which controls the directory used for gems for a given ruby version? What if the directory included the patch level too (if there's a patch level in the ruby name), so you got a different set of gems for each patch level?

For 2.1 there'd be no difference, as, while they do include a patch level in the distributed package name, there is only one patch level for each version level.

For 2.0.0, it would make it so there would be a different set of gems for each installed patch level, which it seems like is the right thing to do for current default rubygems behavior. Yeah, it would be more efficient to share gems between patch levels and not have to install them multiple times, but if that doesn't work with default rubygems configuration... ?

[postmodern]

@jrochkind we just use RUBY_ENGINE and RUBY_VERSION. I've also since opened an issue with rubygems about the explicit #!/path/to/ruby.

[jrochkind]

@postmodern, thanks for opening the issue. But it would make sense for chruby to also use the patch level, if present, in order to avoid this issue?

Seems like potentially a simple change that would entirely avoid this issue -- this can be a confusing issue to deal with when it occurs. The only downside I can think of is if the sharing of installed gems between different patch levels of MRI 2.0.0 is intentional -- but I think not, since you won't get it between different micro-versions of 2.1 anyway.

RUBY_PATCHLEVEL

[jrochkind]

Perhaps as simple as

puts "export RUBY_PATCHLEVEL=#{RUBY_PATCHLEVEL};"

# ...

export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/$RUBY_VERSION-$RUBY_PATCHLEVEL"

[postmodern]

@jrochkind problem is patch-level is only necessary for < 2.0.0. Next year 1.9 will reach EoL and 2.0 shortly afterwards.

[jrochkind]

But does patch level hurt anything else, even if not neccesary? I guess it would disturb present chruby users who need to reinstall all their gems though.

End of Feb 2015 is ruby 1.9 EOL, it is indeed soon. I can't actually find any advertised EOL for ruby 2.0, but would be surprised if it were sooner than a year after that, but who knows.

But okay, perhaps it won't effect very many people at this point, I hear you. Of course, it's already been effecting people for 18 months+, but that's water under the bridge. I have really liked using chruby in general and have been recommending it every chance I get, but I admit concern at the lack of concern for making things work smoothly for users in this case, when a fairly simple solution seemed possible.

[pda]

I think putting up with some temporary rough edges to keep chruby simpler is consistent with its design goals.