> PATH is one answer. > aliasing 'jgem' to 'jruby -S gem' is another. > linking 'gem' to jruby/bin/gem' is another. > running 'jruby -S gem' is another. BTW the problem under discussion isn't on Linux/BSD or other UNIX systems it is on Windows, I hope you are aware that we are talking about the following?
See: http://rubyforge.org/pipermail/rubygems-developers/2008-March/003635.html and http://rubyforge.org/pipermail/rubygems-developers/2008-March/003636.html The problem is that the JRuby gem was always running even when the MRI binary path was in front of it in the PATH variable on Windows. The only solution is to create aliases the other way: to alias /full/path/to/c/ruby/gem to rgem, which is the converse of your solution and still ends up with people using different names for different implementations locally. So scripts, etc. need to take this in consideration anyway, and promotes a non-uniform way of doing things just to get things working like we would expectg. I am no longer on Windows, so I cannot comment, but the PATH switch/aliasing is a PITA either even on Linux. Nobody needs to tell me Windows is not ideal for most open source development that isn't based on .NET or related MS products/languages, but millions of businesses make their developers use it. In theory you are right, there shouldn't be different names for different implementation versions of RubyGems when it is ultimately the same underlying source, however, in practice developers caught out with these issues on Windows are the ones that send tons of emails requesting support to RubyGems. Finger pointing to RubyGems rather than JRuby, when in fact it appears to be a JRuby fault, not RubyGems. Isn't this right Luis? In addition, I see RubyGems as an extension (not necessarily as in Ruby/C extension, just in the general meaning of "extension") to a Ruby implementation than just another gem, so I would argue that it could go either way. Has anyone contacted JRuby about these issues and know what the status of their fix is and when it is expected to be released? If it isn't resolved or planned to be shortly is the RubyGems project willing to take the hit for a JRuby issue that they do not deem important to solve? Just curious Susan _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
