- edited description
uru auto not working as expected with .ruby-version file
I can't seem to get uru auto working with my ruby-version files. I have several projects where these files work fine with rbenv (OSX/WSL), but not uru (Windows).
Here's a distilled repro:
$ mkdir test
$ cd .\test\
$ echo '2.4.3' > .ruby-version
$ cat .\.ruby-version
2.4.3
$ uru auto
---> unable to find or process a .ruby-version
file
$ uru ls
243p205 : ruby 2.4.3p205 (2017-12-14 revision 61247) [i386-mingw32]
Marking as "bug" since from what I can tell, uru auto should be able to read this file.
Comments (14)
-
reporter -
reporter - edited description
-
reporter - edited description
-
reporter I manually re-added 243p205 with the tag "2.4.3", and now uru auto works as expected. So I guess a workaround is to manually duplicate all rubies known to uru so that their tags are ruby-verison compatible. But I still think this is a bug.
-
repo owner That is surprising behavior.
What shell did you use when you ran
echo '2.4.3' > .ruby-version
, and what is the actual content of the file?When I used windows cmd.exe the single quotes you used to surround
2.4.3
made it into.ruby-version
rather than the raw version. Single quotes into.ruby-version
didn't happen when I used an msys2 bash shell on windows and your sameecho
.Without having looked into, if your original
.ruby-version
did have single quotes like'2.4.3'
, that could have borked the search on windows. Don't know why anuru admin tag ... 2.4.3
would have solved this, but... -
reporter the actual content of the file?
32 2e 34 2e 33 0d 0a, so there's \r\n. I also tried removing that, and also just \n, same behavior
What shell
powershell
quotes
nope, it's just
2.4.3\r\n
-
repo owner Thought it might be #86, but no, your
.ruby-version
is ASCII.uru auto
uses the.ruby-version
value to search against the tag value. Tagging your 2.4.3p205 version as2.4.3
isuru's
currently expected behavior.PS $ echo '2.4.3' | out-file -encoding ascii .ruby-version PS $ uru ls 243p205-x64 : ruby 2.4.3p205 (2017-12-14 revision 61247) [x64-mingw32] 250p0-x64 : ruby 2.5.0p0 (2017-12-25 revision 61468) [x64-mingw32] PS $ uru auto ---> unable to find or process a `.ruby-version` file PS $ rm .\.ruby-version PS $ echo '243' | out-file -encoding ascii .ruby-version PS $ uru auto ---> now using ruby 2.4.3-p205 tagged as `243p205-x64` PS $ uru ls => 243p205-x64 : ruby 2.4.3p205 (2017-12-14 revision 61247) [x64-mingw32] 250p0-x64 : ruby 2.5.0p0 (2017-12-25 revision 61468) [x64-mingw32]
It's the old feature-not-a-bug. If you feel strongly, change this to an enhancement request and I'll look into it when I can.
Or feel free to submit a pull request if you write
go
. This code and this code are the two key places to start with theenv.RubyMap
andRuby
data structures here starting on L34 and theenv.TagLabelToTag
fcn here doing the matching IIRC. -
reporter Why does this same .ruby-version file work fine with rbenv, then? Shouldn't uru be compatible?
-
repo owner It works with rbenv and not with uru likely because it appears I didn't implement .ruby-version support in a compatible way. Uru likely just needs to add support for fuzzy searching the output of
ruby --version
. -
repo owner See if
uru-0.8.5-rc1
in downloads fixes it.$ uru ver uru v0.8.5.rc1 [windows/386 go1.10] $ uru ls 243p205-x64 : ruby 2.4.3p205 (2017-12-14 revision 61247) [x64-mingw32] 250p0-x64 : ruby 2.5.0p0 (2017-12-25 revision 61468) [x64-mingw32] $ echo 2.4.3 > .ruby-version $ xxd -u .ruby-version 00000000: 322E 342E 3320 0D0A 2.4.3 .. $ uru auto ---> now using ruby 2.4.3-p205 tagged as `243p205-x64` $ uru ls => 243p205-x64 : ruby 2.4.3p205 (2017-12-14 revision 61247) [x64-mingw32] 250p0-x64 : ruby 2.5.0p0 (2017-12-25 revision 61468) [x64-mingw32] $ ruby --version ruby 2.4.3p205 (2017-12-14 revision 61247) [x64-mingw32]
-
repo owner Verify better impl in new
uru-0.5.8-rc2
download. -
reporter It works! Wonderful, thank you.
-
repo owner - changed status to closed
Refactor ruby version matching. Closes
#101→ <<cset 1e83492207b1>>
-
repo owner -
assigned issue to
-
assigned issue to
- Log in to comment