I'd like to be able to add all installed rubies at once

[Zac Stewart]

Something like uru admin add -r ~/.rubies would be nice

[Jon]

I like the idea as I also keep all my rubies in subdirs of ~/.rubies on my *nix machines.

That said, how do you suggest handling scenarios in which people install rubies to other not-so-organized locations, say /opt/ruby-1.9.3, ~/ruby-2.0.0, /usr/local/ruby-2.0.0-x64 or C:\Apps\ruby-2.0.0, C:\ruby-2.1.0-x32, D:\testing\ruby-2.0.0-x64?

[Zac Stewart]

I would just leave urn admin add PATH the way that it is, but add the -r flag to mean "recursively search this path for Rubies." Also, maybe support *nix-style path wildcards like this: urn admin add -r /opt/ruby-*

[Jon]

I'll start with your uru admin add -r ~/.rubies suggestion in which the subdir basename's become the tag aliases for each ruby.

A more generic uru admin add PATH... in addition to the -r option may come later.

[Jon]

IMPL NOTES:

1. Ensure append-only behavior to the registry; do not overwrite existing registered rubies.
2. Only conflict scenario is when new ruby dir matches the dir of a currently registered ruby. No overwrites by default; --force option added later? Give error message, don't register the new ruby, and continue to iterate. It is not a conflict to have multiple registrations of the same ruby version as long as each ruby lives in a different fs location.
3. Do not allow custom tagging during recursive adds. Default tag name is derived not from subdir name but from ruby version string as is currently done for non-recursive adds. Add --dir-tag option to derive default tag names from subdir names?

[Jon]

@zacstewart what platform (linux, osx) are you using?

I'm starting impl this weeked and will likely have builds I'd like you to test in order to solidify the feature. I'd like to include the feature in the upcoming 0.7.1 release, but we'll see how long it takes to refine.

[Zac Stewart]

I'm on OSX.

[Jon]

Quick testing on Win8.1 64-bit and Arch and Ubuntu Server 64-bit looks promising. Let me know how it works for you.

To bulk register rubies already installed to a base directory, use either this style

uru admin add --recurse ~/.rubies

which registers the rubies using default tag labels generated from the ruby description, or this style

uru admin add --recurse ~/.rubies --dirtag

which registers rubies using tag labels generated from dir names.

I've also updated deregistration to allow deregistering all rubies in one shot like

uru admin rm --all

[Zac Stewart]

The new feature works great!

 ~  ⌁  uru admin rm --all

OK to deregister all rubies? [Yn] y
 ~  ⌁  uru ls
---> No rubies registered with uru
 ~  ⌁  uru admin add -r ~/.rubies/
---> Unable to find a known ruby at `/Users/zacstewart/-r`
 ~  ⌁  uru admin add --recurse ~/.rubies/
---> Registered ruby at `/Users/zacstewart/.rubies/ruby-1.9.3-p448/bin` as `193p448`
---> Registered ruby at `/Users/zacstewart/.rubies/ruby-2.0.0-p247/bin` as `200p247`
 ~  ⌁  uru ls
    193p448     : ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin13.0.0]
    200p247     : ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]

However, did the functionality of adding sys ruby change?

 ~  ⌁  uru admin add system
---> Unable to find a known ruby at `/Users/zacstewart/system`

I had to manually add it specifying the path and tag

 ~  ⌁  uru admin add /usr/bin --tag system
---> Registered ruby at `/usr/bin` as `system`
 ~  ⌁  uru ls
    193p448     : ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin13.0.0]
    200p247     : ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]
 => system      : ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-dar...

[Jon]

I might have broken system. Or perhaps you've found a old sequencing bug regarding when a system ruby can be added wrt other rubies.

Please try the following and lets see what happens

$ uru admin rm --all
$ cd <dir you installed uru_rt>
$ uru_rt admin add system
$ cd ~
$ uru admin add --recurse ~/.rubies/
$ # test, test, test...

If the above seems to work I'm betting that adding a system ruby when PATH has already been infected by uru is the problem. I use "canaries", ::: on *nix, to logically separate PATH into a uru controlled part and a base part. Trying to add a system ruby to a PATH already managed by uru and containing canaries could lead to problems.

Try this as well

$ uru admin rm -all
$ uru admin add --recurse ~/.rubies/
$ uru nil
# ensure no uru controlled rubies are on PATH
$ echo $PATH  # ensure no ::: canaries are part of path
$ uru admin add system

[Zac Stewart]

 ~  ⌁  uru admin rm --all

OK to deregister all rubies? [Yn] y
 ~  ⌁  cd .bin
 ~/.bin  ⌁  ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]
 ~/.bin  ⌁  ./uru_rt admin add syste
---> Unable to find a known ruby at `/Users/zacstewart/.bin/syste`
 ~/.bin  ⌁  ./uru_rt admin add system
---> Unable to find a known ruby at `/Users/zacstewart/.bin/system`
 ~/.bin  ⌁  uru nil
 ~/.bin  ⌁  echo $PATH
/Users/zacstewart/.bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:/Users/zacstewart/.bin:/usr/local/sbin
 ~/.bin  ⌁  uru admin add system
---> Unable to find a known ruby at `/Users/zacstewart/.bin/system`
 ~/.bin  ⌁  ./uru_rt admin add system
---> Unable to find a known ruby at `/Users/zacstewart/.bin/system`

[Jon]

Thanks. I've broken system; link to updated test builds once I find/fix it.

[Jon]

See if this build gets us back to having a working system and all the new features.

[Jon]

Release uru 0.7.1. Closes #34 #35 and #48

→ <<cset 41a6ab93464f>>