- edited description
is uru deleting my GEM_HOME?
uru seems to be deleting my GEM_HOME env variable.
I'm using Windows 7 in ConEmu
Here's what happens: opening a new shell in ConEmu, at first I have GEM_HOME defined. After I set a ruby using uru, then I no longer have GEM_HOME set. (And I see below that uru never has any value for GemHome
. Should it?) :
#!
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\ashley\Documents\dev\git\repos>set GEM_HOME
GEM_HOME=C:\rubys\ruby-2.1.6-p336-x64\lib\ruby\gems\2.1.0
GEM_HOMES-to-be-used=C:\rubys\ruby-2.0.0-p598-i386-mingw32\lib\ruby\gems\2.0.0;C:\rubys\ruby-2.1.5-p273-i386-mingw32\lib\ruby\gems\2.1.0;C:\rubys\ruby-2.1.5-p273-x64-mingw32\lib\ruby\gems\2.1.0;C:\rubys\ruby-2.0.0-p247-i386-mingw32\lib\ruby\gems\2.0.0;C:\RailsInstaller\Ruby1.9.3\lib\ruby\gems\1.9.1
C:\Users\ashley\Documents\dev\git\repos>uru ls --verbose
193p448 : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
ID: 1.9.3-p448
Home: C:\rubys\ruby-1.9.3-p448-i386-mingw32\bin
GemHome:
200p598i86 : ruby 2.0.0p598 (2014-11-13) [i386-mingw32]
ID: 2.0.0-p598
Home: c:\rubys\ruby-2.0.0-p598-i386-mingw32\bin
GemHome:
215p273 : ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
ID: 2.1.5-p273
Home: C:\rubys\ruby-2.1.5-p273-x64-mingw32\bin
GemHome:
215p273x86 : ruby 2.1.5p273 (2014-11-13 revision 48405) [i386-mingw32]
ID: 2.1.5-p273
Home: c:\rubys\ruby-2.1.5-i386-mingw32\bin
GemHome:
215x64 : ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
ID: 2.1.5-p273
Home: c:\rubys\ruby-2.1.5-x64-mingw32\bin
GemHome:
216-336-x : ruby 2.1.6p336 (2015-04-13 revision 50298) [x64-mingw32]
ID: 2.1.6-p336
Home: C:\rubys\ruby-2.1.6-p336-x64\bin
GemHome:
216p336 : ruby 2.1.6p336 (2015-04-13 revision 50298) [i386-mingw32]
ID: 2.1.6-p336
Home: C:\rubys\ruby-2.1.6-p336-i386\bin
GemHome:
221p85 : ruby 2.2.1p85 (2015-02-26 revision 49769) [i386-mingw32]
ID: 2.2.1-p85
Home: c:\rubys\ruby-2.2.1-i386-mingw32\bin
GemHome:
221p85x64 : ruby 2.2.1p85 (2015-02-26 revision 49769) [x64-mingw32]
ID: 2.2.1-p85
Home: C:\rubys\ruby-2.2.1-p85-x64-mingw32\bin
GemHome:
222p95 : ruby 2.2.2p95 (2015-04-13 revision 50295) [x64-mingw32]
ID: 2.2.2-p95
Home: C:\rubys\ruby-2.2.2-p95-x64\bin
GemHome:
222p95i386 : ruby 2.2.2p95 (2015-04-13 revision 50295) [i386-mingw32]
ID: 2.2.2-p95
Home: c:\rubys\ruby-2.2.2-p95-i386\bin
GemHome:
C:\Users\ashley\Documents\dev\git\repos>uru 216-336-x
---> Now using ruby 2.1.6-p336 tagged as `216-336-x`
C:\Users\ashley\Documents\dev\git\repos>set GEM_HOME
GEM_HOMES-to-be-used=C:\rubys\ruby-2.0.0-p598-i386-mingw32\lib\ruby\gems\2.0.0;C:\rubys\ruby-2.1.5-p273-i386-mingw32\lib\ruby\gems\2.1.0;C:\rubys\ruby-2.1.5-p273-x64-mingw32\lib\ruby\gems\2.1.0;C:\rubys\ruby-2.0.0-p247-i386-mingw32\lib\ruby\gems\2.0.0;C:\RailsInstaller\Ruby1.9.3\lib\ruby\gems\1.9.1
C:\Users\ashley\Documents\dev\git\repos>uru ls --verbose
193p448 : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
ID: 1.9.3-p448
Home: C:\rubys\ruby-1.9.3-p448-i386-mingw32\bin
GemHome:
200p598i86 : ruby 2.0.0p598 (2014-11-13) [i386-mingw32]
ID: 2.0.0-p598
Home: c:\rubys\ruby-2.0.0-p598-i386-mingw32\bin
GemHome:
215p273 : ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
ID: 2.1.5-p273
Home: C:\rubys\ruby-2.1.5-p273-x64-mingw32\bin
GemHome:
215p273x86 : ruby 2.1.5p273 (2014-11-13 revision 48405) [i386-mingw32]
ID: 2.1.5-p273
Home: c:\rubys\ruby-2.1.5-i386-mingw32\bin
GemHome:
215x64 : ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
ID: 2.1.5-p273
Home: c:\rubys\ruby-2.1.5-x64-mingw32\bin
GemHome:
=> 216-336-x : ruby 2.1.6p336 (2015-04-13 revision 50298) [x64-mingw32]
ID: 2.1.6-p336
Home: C:\rubys\ruby-2.1.6-p336-x64\bin
GemHome:
216p336 : ruby 2.1.6p336 (2015-04-13 revision 50298) [i386-mingw32]
ID: 2.1.6-p336
Home: C:\rubys\ruby-2.1.6-p336-i386\bin
GemHome:
221p85 : ruby 2.2.1p85 (2015-02-26 revision 49769) [i386-mingw32]
ID: 2.2.1-p85
Home: c:\rubys\ruby-2.2.1-i386-mingw32\bin
GemHome:
221p85x64 : ruby 2.2.1p85 (2015-02-26 revision 49769) [x64-mingw32]
ID: 2.2.1-p85
Home: C:\rubys\ruby-2.2.1-p85-x64-mingw32\bin
GemHome:
222p95 : ruby 2.2.2p95 (2015-04-13 revision 50295) [x64-mingw32]
ID: 2.2.2-p95
Home: C:\rubys\ruby-2.2.2-p95-x64\bin
GemHome:
222p95i386 : ruby 2.2.2p95 (2015-04-13 revision 50295) [i386-mingw32]
ID: 2.2.2-p95
Home: c:\rubys\ruby-2.2.2-p95-i386\bin
GemHome:
C:\Users\ashley\Documents\dev\git\repos>
Comments (5)
-
reporter -
repo owner Uru doesn't currently provide any support for what you are trying to do via
GEM_HOME
.Long answer: when uru switches rubies, I currently try to ensure that the default available gems "match" the new ruby in order to prevent any version mismatch problems. As summarized here the convention-over-configuration is to set
GEM_HOME
to the form/home/$USER/.gem/$ruby/$version
on Linux/OSX. On Windows, the current convention is to setGEM_HOME
to the empty string, which is why yourGEM_HOME
setting is being rudely clobbered by uru. The current convention is that on Windows, all gems are installed into the ruby install tree; on Linux/OSX, all gems are installed in namespaced dirs in a users$HOME/.gem
tree.The problem I'm trying to keep from happening is that certain gems work OK with a particular ruby, but then fail for some reason when used with a different ruby. This will likely never happen with pure ruby gems, but is a concern for C-based gems. For example, a non-fat, C-based gem (i.e. - a non-multiversion binary) installed for your your 2.1.5 ruby will be linked against
msvcrt-ruby210.dll
. However, when used with your 2.2.2 ruby, this same gem needs to be linked againstmsvcrt-ruby220.dll
so that it doesn't fail. Uru's current behavior prevents the scenario in which you've put the 2.1.5 C-based gem inGEM_HOME
and it works OK with ruby 2.1.5 but then fails when switching to ruby 2.2.2 because themsvcrt-ruby210.dll
lib isn't available.That said, uru's current "ultra safe" strategy has a few problems:
- On Windows, fat, C-based gems like ffi which support multiple ruby versions by having separate C-based libs in separate
lib/X.Y
dirs and customrequire
code should be fine for the scenario I described. - A user isn't easily able to provide a shared gem location that they know works across multiple rubies. Given how cheap HDD space is these days, I don't view this as a major concern, but I do view it as an inconvenience.
- Uru's current behavior wrt
GEM_HOME
andGEM_PATH
need to change in do what I want for #53.
Bottom line...I want to leave this issue open for awhile to get more feedback on how people are thinking of using
GEM_HOME
orGEM_PATH
. Both in the gemset scenario as per #53 as well as other scenarios. While I believe uru's current behavior makes the right set of tradeoffs, I also think more usable and creative solutions exist. I'd like to explore them. - On Windows, fat, C-based gems like ffi which support multiple ruby versions by having separate C-based libs in separate
-
reporter Thanks for the long answer. I agree with your approach to wait and see how usage really shakes out; that's totally sensible. As for my particular usage: I always change
GEM_HOME
to be synchronized with my current version of ruby in part so that any gems that were natively compiled will be linked correctly and will work with (and only work with) its appropriate version of ruby. I'd been doing that with a series of .BAT files that I'd run when I switched ruby versions. It sounds like what you're planning for gemsets will take care of this for me.
That issue aside, I'm really happy with uru. Thanks again for your work on it!Perhaps you can link to your above 'long answer' to the wiki, in case someone has the same question/issue as I did. Maybe in Usage, in the "Background" section after "... and sets a GEM_HOME value if applicable." you could add something like "(Read more below about
GEM_HOME
on Windows.)" and link that parenthetical to "2. Correct GEM_HOME values may conflict with default user installed gems" in the "Known (Surprising?) Behaviors" section. And maybe link your 'long answer' above in the "2. Correct GEM_HOME values may conflict with default user installed gems" section.I wish BitBucket allowed users to search wikis. I think I might have found the answer to my own issue. Ah well.
-
reporter - changed status to closed
-
repo owner Agreed. I'll update the wiki.
You might try playing with
GEM_PATH
to see if you can come up with something that works for what you're trying to do since uru currently has no code that tweaksGEM_PATH
.C:\>uru ver uru v0.8.0.rc2 [windows/386 devel +d23973d Fri Jul 24 05:19:09 2015 +0000] C:\>uru ls 217p379-x32 : ruby 2.1.7p379 (2015-07-07 revision 51178) [i386-mingw32] => 223p147-x32 : ruby 2.2.3p147 (2015-07-04 revision 51143) [i386-mingw32] jruby : jruby 9.0.0.0 (2.2.2) 2015-07-21 e10ec96 Java HotSpot(TM) 64-Bit... C:\>set GEM_ Environment variable GEM_ not defined C:\>gem env RubyGems Environment: - RUBYGEMS VERSION: 2.4.8 ... - GEM PATHS: - C:/Apps/rubies/ruby-2.2/lib/ruby/gems/2.2.0 - C:/Users/Jon/.gem/ruby/2.2.0 C:\>set GEM_PATH=C:\path\to\safely\shared\rubies C:\>gem env RubyGems Environment: - RUBYGEMS VERSION: 2.4.8 ... - GEM PATHS: - C:/Apps/rubies/ruby-2.2/lib/ruby/gems/2.2.0 - C:/path/to/safely/shared/rubies
That said, to implement isolated gemsets as in #53 I may have to use
GEM_PATH
andGEM_HOME
similar toC:\>set GEM_HOME=C:\path\to\gemset && set GEM_PATH=C:\path\to\gemset C:\>gem env RubyGems Environment: - RUBYGEMS VERSION: 2.4.8 ... - GEM PATHS: - C:/path/to/gemset - C:/path/to/gemset
- Log in to comment