rvm bin path cry cry cry

gistfile1.sh

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?

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"

@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

@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

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

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

Arch linux ships it's own gemrc? wat?

Yeah, that would do it… Adding:

gem: --no-user-install

to ~/.gemrc would fix it.

@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!

hahaha awesome guys!

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

just talked with #rubygems - filling in an issue

so this two should fix it:

• rubygems/rubygems#291
• rubygems/rubygems#292

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

@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

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

@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.

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.