admin add: Identify i386 and x64 as same platform

[Luis Lavena]

Hello,

First and most important, thank you for creating and sharing this!

I'm trying to add both Ruby 2.0.0-p0 x86 (i386-mingw32) and x64 (x64-mingw32) versions to uru and is failing:

C:\Users\Luis\Tools\Ruby>uru admin add ruby-2.0.0-p0-i386-mingw32\bin
---> Registered ruby at `ruby-2.0.0-p0-i386-mingw32\bin` as `200p0`

C:\Users\Luis\Tools\Ruby>uru admin add ruby-2.0.0-p0-x64-mingw32\bin
---> Skipping. `ruby-2.0.0-p0-x64-mingw32\bin\ruby.exe` is already registered.

Perhaps this is caused by usage of ID not considering the platform?

Thank you!

[Jon]

Hi Luis, it's been awhile.

Thanks for testing and I think this is part of the current tag/ID scheme not being smart enough yet to handle (a) multiple (patched) flavors of the same ruby version as in #18, and (b) not accounting for platform/arch as you mention.

The little uru puppy needs more training ;)

[Jon]

initial impl plan:

1. update auto-generated tag code - when adding rubies (from separate dirs) in which the new generated tag collides with an existing tag, create a generic sequenced tag, eg 200p0, 200p0-1. May need to switch to more complex regex scanning of ruby --version if default tags like 200p0-x64 work better.
2. fix current codes (eg uru ls) broken by (1)...likely need to check ruby home paths and tags and fix display width hard coded assumptions.
3. implement admin add --tag TAG to allow for custom tag values at registration time.
4. change previously registered skip behavior; give user the ability to overwrite an existing ruby registration if they return Y from prompt.

In general, uru shouldn't need to know about a platform's arch (x86, x64). It just needs to get the tag naming correct for multiple rubies in different dirs that happen to cause the tag generator to create colliding default tag values.

[Jon]

Refactoring tag impl and usage to solve this and #18. Impl occurring on hash-tags branch.

[Jon]

Refactor ruby tag impl. Fixes #18, fixes #21

Tag values used to identify a specific ruby will be string hash values rather than strings generated from parsing ruby --version. Tags will not be user visable, but will provide one level of indirection to a user visable TagLabel. This scheme will allow multiple flavors of the same ruby version to coexist and enable tag value customization by the user.

→ <<cset a3192adbbf63>>