Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
rvm bin path cry cry cry
temp (ree-1.8.7-2012.02@global)$ gem install bundler
WARNING: You don't have /home/trevor/.gem/ruby/1.8/bin in your PATH,
gem executables will not run.
Successfully installed bundler-1.0.22
1 gem installed
Installing ri documentation for bundler-1.0.22...
Installing RDoc documentation for bundler-1.0.22...
temp (ree-1.8.7-2012.02@global)$ gem -v
1.8.17
temp (ree-1.8.7-2012.02@global)$ which gem
/home/trevor/.rvm/rubies/ree-1.8.7-2012.02/bin/gem
temp (ree-1.8.7-2012.02@global)$ which ruby
/home/trevor/.rvm/rubies/ree-1.8.7-2012.02/bin/ruby
temp (ree-1.8.7-2012.02@global)$

What's your gem env say?

Owner

TrevorBramble commented Mar 5, 2012

case "$-" in
*i*) # Code for interactive shell here
  source ~/bin/dotfiles/bash/env
  source ~/bin/dotfiles/bash/config
  source ~/bin/dotfiles/bash/aliases
;;
*)
# Code for non-interactive shell here
;;
esac

export PATH=$HOME/local/bin:$PATH

# This loads RVM into a shell session.
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
Owner

TrevorBramble commented Mar 5, 2012

@tenderlove

temp (ree-1.8.7-2012.02@global)$ gem env
gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.17
  - RUBY VERSION: 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]
  - INSTALLATION DIRECTORY: /home/trevor/.rvm/gems/ree-1.8.7-2012.02@global
  - RUBY EXECUTABLE: /home/trevor/.rvm/rubies/ree-1.8.7-2012.02/bin/ruby
  - EXECUTABLE DIRECTORY: /home/trevor/.rvm/gems/ree-1.8.7-2012.02@global/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /home/trevor/.rvm/gems/ree-1.8.7-2012.02@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "gem" => "--user-install"
  - REMOTE SOURCES:
     - http://rubygems.org/
printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"
~/.rvm/bin/rvm-prompt))$(__git_ps1 " (%s)")\$ 
~/.rvm/bin/rvm-prompt
__git_ps1 " (%s)")\$ 
__git_ps1 " (%s)"
__gitdir)"
__gitdir)
__gitdir

mpapis commented Mar 5, 2012

@tenderlove you found it, it's gem: --user-install in /etc/gemrc

I think the - "gem" => "--user-install" line is your problem (possibly). I think that option is trying to load the gems in to your home directory, when you don't really want that happening with rvm (unless that's actually what you want). Not sure where that option is being set though.

@drbrain can you confirm?

@mpapis ah, okay. My guess is correct then. :-D

mpapis commented Mar 5, 2012

it's 3rd report for RVM on Arch Linux -> http://www.archlinux.org/packages/extra/x86_64/ruby/files/

I need to find a way to prevent it or at least warn users about it

Owner

TrevorBramble commented Mar 5, 2012

@mpapis @tenderlove You guys rock. Pushing this along on the Arch side now.

Arch linux ships it's own gemrc? wat?

drbrain commented Mar 5, 2012

Yeah, that would do it… Adding:

gem: --no-user-install

to ~/.gemrc would fix it.

Owner

TrevorBramble commented Mar 5, 2012

@tenderlove New thing. I guess things get weird when you install libraries via two different package managers at two different abstraction levels. Who knew?

@drbrain Huge success. Thanks!

ddd commented Mar 6, 2012

hahaha awesome guys!

mpapis commented Mar 7, 2012

after further checking I fund out that whole line of rubies (1.8) does not respect the RbConfig::CONFIG['sysconfdir']

checked with:

rvm 1.8.7 do ruby -rrbconfig -e "puts RbConfig::CONFIG['sysconfdir']" 

would it be ruby or gem bug ? the same version of rubygems uses /etc/gemrc on 1.8.7 and does not use it on 1.9.3

mpapis commented Mar 7, 2012

just talked with #rubygems - filling in an issue

mpapis commented Mar 7, 2012

so this two should fix it:

Owner

TrevorBramble commented Mar 7, 2012

@mpapis You are awesome. Thank you so much for chasing this down the stack!

mpapis commented Mar 7, 2012

@TrevorBramble it's not end of the story -> https://bugs.ruby-lang.org/issues/6121 ... maybe we could get @tenderlove have a look on it

Owner

TrevorBramble commented Mar 7, 2012

Whoops! Just saw him a few hours ago.

@mpapis I have no idea on this one. But I bet @luislavena would know.

@mpapis Usaku Nakamura will be the best person to answer that inconsistency.

Windows do not have a common place to store these settings in the filesystem (contrary to the registry). The recommendation of using All Users Program Data sounds reasonable as is the place were all programs store files common to all users.

For example, under Windows 7:

C:\Users\Luis>ruby -retc -e "puts Etc.sysconfdir"
C:/ProgramData

That matches with %PROGRAMDATA% environment variable, and is the recommended place to store per system configuration files:

http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx

mpapis commented Mar 11, 2012

@luislavena - that's my point, it's kind a unfair, it allows windows users to control the sysconfdir while linux/osx users are forced to use settings used during compilation ... this is inconsistent behavior, forcing developers to create separate mechanisms for windows and other systems

if we allow to change it on windows during run time why would we not allow it also on linux ... maybe I'm sort of jealous for windows users having this kind'a comfort.

for me best output of this would be to move using sysconfdir as a fallback for a case when there is no PROGRAMDATA

ENV['PROGRAMDATA'] || RbConfig::CONFIG['sysconfdir']

win win ... at least for me

@mpapis:

Well, it matches the environment variable, sure, but is not controllable by the environment variable itself:

C:\Users\Luis>set ProgramData=C:\Foo

C:\Users\Luis>ruby -retc -e "puts ENV['ProgramData'], Etc.sysconfdir"
C:\Foo
C:/ProgramData

It uses WinAPI to obtain the value and that is buried in Windows Registry.

mpapis commented Mar 11, 2012

sure it's windows way of fixing problems with inheriting environment, but you can change it in registry and then any new call / run will use it - so you can change it, and on linux - it's hardcoded, at least unless you mess with RbConfig, but I think it's still getting to my point - it's not consistent behavior.

it also starts to make sense when I want to use shoesrb to build portable applications runnable on all the available platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment