Windows: uru adds relative instead of absolute paths
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)
-
repo owner -
repo owner This may be an issue with how you used
uru admin add ...
to register yourruby 2.1.4p265
install with uru.Please show me the contents of your
$env:USERPROFILE\.uru\rubies.json
file similar toPS 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]" } } }
-
repo owner -
assigned issue to
-
assigned issue to
-
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]" } } }
-
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.
-
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.
-
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.
-
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.
-
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-providedtag 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 internaltag
and user providedtag label
is best seen by looking at arubies.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.
-
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]
-
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.)
-
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?
-
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.
-
repo owner - changed status to closed
Do not alias local vars. Closes
#61→ <<cset a1a448484de3>>
-
It works!
- Log in to comment
I cannot repro this one either. Let's try figuring out the problem to
#63first as it may be affecting this one too.Contents of
$env:USERPROFILE\.uru\uru_lackee.ps1