update `uru refresh` behavior and add `--retag` option

[Luis Lavena]

Hello,

When doing uru refresh, any custom tag applied by retag or add ... --tag gets lost:

C:\Users\Luis>uru --version
uru v0.6.2

C:\Users\Luis>uru ls
    187p374     : ruby 1.8.7 (2013-06-27 patchlevel 374) [i386-mingw32]
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
 => 200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
    200p247-x64 : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]

C:\Users\Luis>uru admin refresh
---> refreshing ruby tagged as `200p247`
---> refreshing ruby tagged as `187p374`
---> refreshing ruby tagged as `193p448`
---> refreshing ruby tagged as `200p247-x64`

C:\Users\Luis>uru ls
    187p374     : ruby 1.8.7 (2013-06-27 patchlevel 374) [i386-mingw32]
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
 => 200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
    200p247     : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]

C:\Users\Luis>uru 200p247-x64
---> unable to find registered ruby matching `200p247-x64`

C:\Users\Luis>uru admin retag 200p247 200p247-x64
---> these rubies match your `200p247` tag:

 [1] 200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
                   Home: C:\Users\Luis\Tools\Ruby\ruby-2.0.0-p247-i386-mingw32\bin
 [2] 200p247     : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]
                   Home: C:\Users\Luis\Tools\Ruby\ruby-2.0.0-p247-x64-mingw32\bin

select [1]-[2] to retag that specific ruby (0 to exit) [0]: 2
---> retagged `200p247` to `200p247-x64

[Jon]

Yes, and it's irritating ;)

I need to spend a little time teaching the refresh logic how to distinguish default tag labels from custom tag labels, but I think the replacement logic could get ugly.

Say I've tagged a 200p247-x64 and upgrade to 200p255. I probably want a new tag of 200p255-x64. But what if my tag was My200? After the upgrade I probably still want My200. The search/replace logic needs to be smart enough to handle both scenarios.

I haven't thought about this enough, so I've gone the manual route of letting the user take care of refresh tagging oddities. But I'm open to clever ease-of-use ideas that don't add too much code complexity :)

[Luis Lavena]

Interesting, as I always install new Rubies into different directories (even same patchlevel)

Used refresh because I removed some old rubies and didn't want to manually remove each one.

Perhaps a simple comparison between the detected tag versus the entered tag will be enough to determine if needs to be replaced by the detected one.

Either way, is not a blocker for me.

Thank you.

[Jon]

Ah, nice. I hadn't considered there's at least two types of refresh workflows:

1. Refresh (add/remove rubies) the entire registry but each registered ruby and tag stays the same
2. Refresh (update) each registered ruby's tag to latest patch level

I use (2) and have just the latest patch levels of each 1.9.3, 2.0.0, 2.1.0 and overwrite the installation dirs. It's my Arch rolling release pov and therefore uru's default behavior.

But (1) may be the more generally expected default behavior of uru as a ruby switcher. There's no one size fits all, but I'll look into changing uru's default behavior to (1) and try to support (2) with a cmd line option.

What do you these?

• uru admin refresh - maintain all existing custom tags; usage (1)
• uru admin refresh --reset - reset all tags to default calculated value; usage (2)

[Luis Lavena]

I like --reset suggestion or perhaps --retag to fit better with the purpose?

Thank you!

[Jon]

Nice, uru admin refresh --retag it is :)

Thanks!

[Jon]

How does 0.6.3.alpha1 on the downloads page work for you (both scenarios)?

[Luis Lavena]

Yup, both scenarios work perfectly!

C:\Users\Luis>uru ls
    187p370     : ruby 1.8.7 (2012-06-29 patchlevel 370) [i386-mingw32]
    187p374     : ruby 1.8.7 (2013-06-27 patchlevel 374) [i386-mingw32]
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
    200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
    200p247-x64 : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]

C:\Users\Luis>uru admin refresh
---> refreshing ruby tagged as `200p247`
---> refreshing ruby tagged as `187p374`
---> refreshing ruby tagged as `193p448`
---> refreshing ruby tagged as `200p247-x64`
---> ruby tagged as `187p370` does not exist; deregistering

C:\Users\Luis>uru ls
    187p374     : ruby 1.8.7 (2013-06-27 patchlevel 374) [i386-mingw32]
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
    200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
    200p247-x64 : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]

And retag:

C:\Users\Luis>uru admin refresh --retag
---> refreshing ruby tagged as `200p247`
---> refreshing ruby tagged as `187p374`
---> refreshing ruby tagged as `193p448`
---> refreshing ruby tagged as `200p247-x64`

C:\Users\Luis>uru ls
    187p374     : ruby 1.8.7 (2013-06-27 patchlevel 374) [i386-mingw32]
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
    200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
    200p247     : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]

Thank you!

[Jon]

Refactor uru admin refresh behavior. Fixes #39

Uru automagically supports two registry refresh styles. The default is useful when the registered ruby is never updated once registered, or the custom tag label should remain the same across updates. The second style is useful when a registered ruby is regularly updated to the latest patch level and the default generated tag label should be updated to match. The two styles are invoked as:

uru admin refresh # default refresh style uru admin refresh --retag # retag refresh style

Additional refresh and custom tag labeling is supported with the manual use of the uru admin retag command.

→ <<cset 53b58c9de8a6>>