Windows: uru adds relative instead of absolute paths

Issue #61 closed
Former user created an issue

In Powershell, uru doesn't add absolute Ruby paths to the $env:path variable. It adds ruby paths relative to the uru script location. Consequently, unqualified ruby calls only work from the uru install location. My directory structure:

  • C:\Open\ruby-2.1.4-x64-mingw32
  • C:\Open\path\
    • .ruby-version
    • uru.bat
    • uru.ps1
    • uru_rt.exe

Some shell output:

PS C:\Open\path> uru list
 => ruby2       : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]

The content of $env:USERPROFILE\.uru\uru_lackee.ps1:

# autogenerated by uru

$env:PATH = "..\ruby-2.1.4-x64-mingw32\bin;;;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\idmu\common;C:\Program Files\nodejs\;C:\Open\path;C:\Users\Luis\AppData\Roaming\npm"
$env:GEM_HOME = ""

Comments (15)

  1. Jon repo owner

    I cannot repro this one either. Let's try figuring out the problem to #63 first as it may be affecting this one too.

    PS Documents> uru ls
        1715        : jruby 1.7.15 (1.9.3p392) 2014-09-03 82b5cc3 on Java HotSpot(TM) ...
        200p595-x32 : ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]
        215p267-x32 : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
    
    PS Documents> uru 21
    ---> Now using ruby 2.1.5-p267 tagged as `215p267-x32`
    
    PS Documents> uru ls
        1715        : jruby 1.7.15 (1.9.3p392) 2014-09-03 82b5cc3 on Java HotSpot(TM) ...
        200p595-x32 : ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]
     => 215p267-x32 : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
    

    Contents of $env:USERPROFILE\.uru\uru_lackee.ps1

    # autogenerated by uru
    
    $env:PATH = "C:\Apps\rubies\ruby-2.1\bin;;;C:\ProgramData\Oracle\Java\javapath;C:\Apps\CollabNet\Subversion Client;C:\WINDOWS\SYSTEM32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\WBEM;C:\WINDOWS\SYSTEM32\WINDOWSPOWERSHELL\V1.0\;...;C:\tools;C:\Apps\curl\bin;C:\Apps\git\cmd;C:\Apps\Mercurial"
    $env:GEM_HOME = ""
    
  2. Jon repo owner

    This may be an issue with how you used uru admin add ... to register your ruby 2.1.4p265 install with uru.

    Please show me the contents of your $env:USERPROFILE\.uru\rubies.json file similar to

    PS Documents> cat $env:USERPROFILE\.uru\rubies.json
    {
      "Version": "1.0.0",
      "Rubies": {
        "339477364": {
          "ID": "1.7.15",
          "TagLabel": "1715",
          "Exe": "jruby",
          "Home": "C:\\Apps\\rubies\\jruby\\bin",
          "GemHome": "",
          "Description": "jruby 1.7.15 (1.9.3p392) 2014-09-03 82b5cc3 on Java HotSpot(TM) 64-Bit
    Server VM 1.8.0_25-b18 +jit [Windows 8.1-amd64]"
        },
        "3813615672": {
          "ID": "2.0.0-p595",
          "TagLabel": "200p595-x32",
          "Exe": "ruby",
          "Home": "C:\\Apps\\rubies\\ruby-2.0.0\\bin",
          "GemHome": "",
          "Description": "ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]"
        },
        "3895035169": {
          "ID": "2.1.5-p267",
          "TagLabel": "215p267-x32",
          "Exe": "ruby",
          "Home": "C:\\Apps\\rubies\\ruby-2.1\\bin",
          "GemHome": "",
          "Description": "ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]"
        }
      }
    }
    
  3. Luis Marsano

    Using relative paths with uru admin add appears to be the issue. I happened to be in the uru install location when I added a relative path, hence the original post. Here's some output clearly showing it. (In the process, I happened on another possible bug. New bug report?)

    PS C:\Open\path> uru ls
    ---> No rubies registered with uru
    PS C:\Open\path> uru admin add ..\Ruby21-x64\bin --tag ruby2
    ---> Registered ruby at `..\Ruby21-x64\bin` as `ruby2`
    PS C:\Open\path> uru ls --verbose
        ruby2       : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                      ID: 2.1.4-p265
                      Home: ..\Ruby21-x64\bin
                      GemHome:
    
    PS C:\Open\path> uru admin add C:\Open\Ruby21-x64\bin --tag ruby2
    ---> Registered ruby at `C:\Open\Ruby21-x64\bin` as `ruby2`
    PS C:\Open\path> uru ls --verbose
        ruby2       : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                      ID: 2.1.4-p265
                      Home: C:\Open\Ruby21-x64\bin
                      GemHome:
    
        ruby2       : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                      ID: 2.1.4-p265
                      Home: ..\Ruby21-x64\bin
                      GemHome:
    

    rubies.json for relative path:

    {
      "Version": "1.0.0",
      "Rubies": {
        "431455996": {
          "ID": "2.1.4-p265",
          "TagLabel": "ruby2",
          "Exe": "ruby",
          "Home": "..\\Ruby21-x64\\bin",
          "GemHome": "",
          "Description": "ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]"
        }
      }
    }
    
  4. Jon repo owner

    Looks like I've got a code path that does not expand the user provided path to uru admin add into an absolute path. I think the two behaviors you're seeing are the same bug rather than two different bugs.

    Thanks for the details. I'll look into it.

  5. Luis Marsano

    Great. Just to be clear, the other behavior I'm referring to is multiple entries with the same tag. A user would expect the program to prohibit reusing a taken tag, or the new tag assignment to over-write the old. Unless this only happens with the bug, it might be worth attention.

  6. Jon repo owner

    They are related because this code does a string compare of ruby home dirs. The bad double register you see is due to one Home being a relative path and the other Home being an absolute path.

    What is odd is that this code tries to convert the relative path you gave on the cmd line to an absolute path before attempting to register the ruby. It's not working and I suspect it has to do with the way I wrap the uru_rt.exe in script files.

    Good catch, and this is a bug that needs to be fixed. It may take me some time to squash it, so please register your installed rubies with uru using absolute paths as the current workaround.

  7. Luis Marsano

    Though I follow, I was wondering about the general idea. Am I under the mistaken impression that tags should be unique? Giving different rubies the same tag

    C:\Open> uru list --verbose
        2           : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                      ID: 2.1.4-p265
                      Home: C:\Open\Ruby21-x64\bin
                      GemHome:
    
        2           : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                      ID: 2.1.4-p265
                      Home: C:\Open\ruby\bin
                      GemHome:
    
    C:\Open> uru 2
    ---> these rubies match your `2` tag:
    
     [1] 2           : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                       Home: C:\Open\Ruby21-x64\bin
     [2] 2           : ruby 2.1.4p265 (2014-10-27 revision 48166) [x64-mingw32]
                       Home: C:\Open\ruby\bin
    
    select [1]-[2] to use that specific ruby (0 to exit) [0]:
    

    is normal as you intended? This solution works, too, but I wasn't sure it fit your design.

  8. Jon repo owner

    You want your tag label's to be unique rather using the same tag label. Otherwise you get the annoying selection dialog to slow you down.

    As background, uru has the concept of an internally used tag and an arbitrary user-provided tag label. This enables one to have multiple installs of the same ruby version installed in different filesystem locations, each with a custom (usually unique) tag label. The difference between an internal tag and user provided tag label is best seen by looking at a rubies.json file.

    PS Documents> cat $env:USERPROFILE\.uru\rubies.json
    
    {
      "Version": "1.0.0",
      "Rubies": {
        "1884381705": {          <--- this is uru's internal "tag" that uru uses to identify a specific registered ruby
          "ID": "2.1.5-p270",
          "TagLabel": "215p270-x32",    <--- this is the custom "tag label" users provide to make switching between rubies easier
          "Exe": "ruby",
          "Home": "C:\\Apps\\rubies\\ruby-2.1\\bin",
          "GemHome": "",
          "Description": "ruby 2.1.5p270 (2014-11-05 revision 48274) [i386-mingw32]"
        },
        ...
      }
    }
    

    For this bug, root cause appears to be because I'm mistakenly aliasing the user provided install location, but not using the absolute path when registering the ruby.

  9. Jon repo owner

    re: tag labels, use whatever fits your workflow best. Uru tries to support it.

    For example, here are my tag labels at the moment. They're unique-but-similar for 2.1.5. Because uru fuzzy matches when activating a ruby, I get a selection dialog if I specify the similar part of the tag label, but no dialog if I specify the unique part of the tag label:

    C:\>uru ls
        17161       : jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM...
        200p595-x32 : ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]
        215-test    : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
        215p270-x32 : ruby 2.1.5p270 (2014-11-05 revision 48274) [i386-mingw32]
    
    C:\>uru 21
    ---> these rubies match your `21` tag:
    
     [1] 215-test    : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
                       Home: C:\Apps\rubies\ruby-test\bin
     [2] 215p270-x32 : ruby 2.1.5p270 (2014-11-05 revision 48274) [i386-mingw32]
                       Home: C:\Apps\rubies\ruby-2.1\bin
    
    select [1]-[2] to use that specific ruby (0 to exit) [0]: 2
    ---> Now using ruby 2.1.5-p270 tagged as `215p270-x32`
    
    C:\>uru ls
        17161       : jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM...
        200p595-x32 : ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]
        215-test    : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
     => 215p270-x32 : ruby 2.1.5p270 (2014-11-05 revision 48274) [i386-mingw32]
    
    C:\>uru test
    ---> Now using ruby 2.1.5-p267 tagged as `215-test`
    
    C:\>uru ls
        17161       : jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM...
        200p595-x32 : ruby 2.0.0p595 (2014-10-28 revision 48173) [i386-mingw32]
     => 215-test    : ruby 2.1.5p267 (2014-10-28 revision 48177) [i386-mingw32]
        215p270-x32 : ruby 2.1.5p270 (2014-11-05 revision 48274) [i386-mingw32]
    
  10. Luis Marsano

    I would use unique tags, too, but is uru supposed to enforce unique user tags? Your program attempts to enforce unique ruby paths, so (you appear to have decided) a many-to-one correspondence between user tags and ruby paths is incorrect. That still leaves one-to-many unaddressed: is that correspondence correct? My last example uses only absolute ruby paths, so that bug is no longer a factor: same user tag, multiple ruby paths: it's a one-to-many correspondence.

    This is a design specification question rather than a best usage question.

    (I'm aware I appear to be repeating myself, and you may have thought you answered this by writing that custom tags are usually unique. But I had to wonder, "Usually in what sense? The user would usually choose unique custom tags (but is free not to)? The program would usually enforce unique tags (unless a bug interferes)?" The question remains unsettled.)

  11. Jon repo owner

    Use tag label's as you find most helpful for your workflow. Tag labels are effectively arbitrary, user-supplied values. Uru only enforces that the tag label is 12 chars or less. The internally used tag is a unique identifier for a particular registered ruby; the tag is a hash of the ruby description and the ruby install dir.

    Does the 0.7.6.rc.1 version fix this bug for you?

  12. Jon repo owner

    I'm pushing a fix that passes my testing using your relative path example.

    If the soon-to-be released v0.7.6 does not solve this issue for you, please reopen.

  13. Log in to comment