1. Jon Avatar Jon
  2. Untitled project
  3. uru
  4. Issues

is uru deleting my GEM_HOME?

Issue #81 closed
Ashley Engelund created an issue

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)

  2. Jon 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 set GEM_HOME to the empty string, which is why your GEM_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 against msvcrt-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 in GEM_HOME and it works OK with ruby 2.1.5 but then fails when switching to ruby 2.2.2 because the msvcrt-ruby210.dll lib isn't available.

    That said, uru's current "ultra safe" strategy has a few problems:

    1. 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 custom require code should be fine for the scenario I described.
    2. 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.
    3. Uru's current behavior wrt GEM_HOME and GEM_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 or GEM_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.

  3. Ashley Engelund 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.

  5. Jon 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 tweaks GEM_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 and GEM_HOME similar to

    C:\>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
  6. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
closed
Votes
0
Watchers
2
Jira Software: the preferred issue tracker for Bitbucket. Join the team!