1. Jon Avatar Jon
  2. Untitled project
  3. uru
  4. Issues

duplicate tags created for x86 and x64 versions) by admin add --recurse rubys

Issue #75 closed
Ashley Engelund created an issue

I just installed uru and am not quite sure if this is a learning curve issue or a bug. I noticed an older similar issue that has been resolved (#21). I read through that issue but am not sure I'm totally clear on whether automatically generated tags should be unique or not. My assumption is that that they should be unique so that a user can specify which ruby to use. Please let me know if I'm wrong.

I'm running Win 7 x64 and have multiple versions of ruby installed,including some x86 and some x64 versions. They're all under c:\ruby.
I installed uru:

> uru_rt admin install

and that went just fine.

Then I wanted uru to discover the rubys I already have installed:

> uru admin add --recurse c:\rubys

then listed the results:

> C:\dev\bin>uru ls --verbose
    193p448     : ruby 1.9.3p448 (2013-06-27) [i386-mingw32]
                  ID: 1.9.3-p448
                  Home: c:\rubys\ruby-1.9.3-p448-i386-mingw32\bin
                  GemHome:

    200p247     : ruby 2.0.0p247 (2013-06-27) [i386-mingw32]
                  ID: 2.0.0-p247
                  Home: c:\rubys\ruby-2.0.0-p247-i386-mingw32\bin
                  GemHome:

    200p247     : ruby 2.0.0p247 (2013-06-27) [x64-mingw32]
                  ID: 2.0.0-p247
                  Home: c:\rubys\ruby-2.0.0-p247-x64-mingw32\bin
                  GemHome:

    200p598     : ruby 2.0.0p598 (2014-11-13) [i386-mingw32]
                  ID: 2.0.0-p598
                  Home: c:\rubys\ruby-2.0.0-p598-i386-mingw32\bin
                  GemHome:

    215p273     : ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
                  ID: 2.1.5-p273
                  Home: c:\rubys\ruby-2.1.5-x64-mingw32\bin
                  GemHome:

    215p273     : ruby 2.1.5p273 (2014-11-13 revision 48405) [i386-mingw32]
                  ID: 2.1.5-p273
                  Home: c:\rubys\ruby-2.1.5-i386-mingw32\bin
                  GemHome:

    221p85      : ruby 2.2.1p85 (2015-02-26 revision 49769) [x64-mingw32]
                  ID: 2.2.1-p85
                  Home: c:\rubys\ruby-2.2.1-x64-mingw32\bin
                  GemHome:

    221p85      : ruby 2.2.1p85 (2015-02-26 revision 49769) [i386-mingw32]
                  ID: 2.2.1-p85
                  Home: c:\rubys\ruby-2.2.1-i386-mingw32\bin
                  GemHome:

It looks to me like the tags for x86 versions and x64 versions are the same. Shouldn't they be unique?

Thanks.

And thanks for uru! I've tried pik and some other tools and wasn't satisfied. It looks like you have a good approach. (And I'll be glad to dump my set of scripts that I use to manage my PATH, etc. They're ok, but they're such a hack!)

Comments (11)

  2. Jon repo owner

    Glad you like uru and find it helpful 😸

    I try to keep uru from being too clever when it comes to the user defined tag values. I view tag values as being "owned" by the user. Uru should do just the bare minimum and not make too many assumptions about the users dev environment.

    With auto-tagging via bulk recursive adds, you've found the only scenario I'm aware of in which tag values can be duplicated. I was OK with this behavior at the time because I expected people would tweak their tags after the bulk add because the plain vanilla auto-tags were too plain. So much for assumptions.

    That said, the current behavior is a bit annoying as it forces one to do one more config step to make things usable.

    I'll look again at the auto-tagging code and see if I can come up with something more clever by default that (a) works cross-platform, and (b) still doesn't presume too much about the users dev environment.

    I'll look for your feedback on any changes. I may ask for your help testing any new functionality especially since my ruby usage is minimal these days and I do not use 64-bit MRI.

  4. Ashley Engelund reporter

    Happy to help out in whatever way.

    A suggestion: Until you figure out a nice and elegant solution, you might just give information to let them know that the results (duplicate tags) are acknowledged and to suggest the next step. Yes, it's not optimal that it requires a second step from the user, but this way you're making it easy for them by explicitly providing them with the what they need to do next (reducing cognitive load). It might be a message along the lines of "Duplicate tags were automatically generated because of the same ruby version on different processors. You can use 'uru admin retag CURRENTtag NEWtag' to change the tags." (except worded better. my phrasing skills are on hiatus today, apparently.)

    And might I also suggest that you update the wiki documentation to include the info about your goal with tags: 

    I view tag values as being "owned" by the user. Uru should do just the bare minimum 
and not make too many assumptions about the users dev environment. 
There is one scenario with bulk add ( "uru admin add --recursive DIR" )
that may result in duplicate tags: if you have the same version of ruby
 installed with different processors 
(ex: ruby 2.1.5p723 on both i386 and x64), duplicate tags may be auto generated.
 You can simply retag the duplicates.

    Setting expectations is always critical and helps to head off both user and author frustration, yes?

    Thanks for the quick response. I'm happy to help out with testing or whatever. Just let me know.

  5. Jon repo owner

    I agree clarification should be added to the wiki. Maybe a new entry in the Troubleshooting section of the FAQ?

    Short term, I think using the --dirtag option for recursive adds will work great for your scenario. Essentially, if you use --dirtag like uru admin add --recurse c:\rubys --dirtag, uru will autotag each added ruby using the dir name containing each ruby.

    For example, here's how it works on my machine in which I install rubies to C:\Apps\rubies using a dev version of uru. It's not your scenario, but it should give you an idea on how --dirtag and ruby install dir names can make your autotagging nicer.

    C:\>uru ver
uru v0.8.0.beta [windows/386 go1.4.2]

C:\>uru help admin
  Description: administer uru installation
  Aliases: admin
  Usage: uru admin SUBCMD ARGS
  Example: uru admin add C:\Apps\rubies\ruby-2.1\bin

where SUBCMD is one of:
...
     add   register an existing ruby installation
           aliases: add
           usage: uru admin add DIR [--tag TAG] | --recurse DIR [--dirtag] | system
           eg: uru admin add C:\Apps\rubies\ruby-2.1\bin

# what rubies do I have currently registered with uru?
C:\>uru ls
    217p376-x32 : ruby 2.1.7p376 (2015-07-03 revision 51128) [i386-mingw32]
    223p146-x32 : ruby 2.2.3p146 (2015-07-04 revision 51135) [i386-mingw32]

# deregister all rubies from uru...this *does not* uninstall any of your rubies, it simply makes uru forget about them
C:\>uru admin rm --all

OK to deregister all rubies? [Yn]

C:\>uru ls
---> No rubies registered with uru

# what does the parent dir look like that contains all my rubies in subdirs?
C:\>dir \Apps\rubies

 Directory of C:\Apps\rubies

04/30/2015  02:03 AM    <DIR>          ruby-2.1
04/30/2015  02:12 AM    <DIR>          ruby-2.2

# add all rubies in C:\Apps\rubies and autotag using each ruby's base dir name
C:\>uru admin add --recurse \Apps\rubies --dirtag
---> Registered ruby at `C:\Apps\rubies\ruby-2.1\bin` as `ruby-2.1`
---> Registered ruby at `C:\Apps\rubies\ruby-2.2\bin` as `ruby-2.2`

C:\>uru ls
    ruby-2.1    : ruby 2.1.7p376 (2015-07-03 revision 51128) [i386-mingw32]
    ruby-2.2    : ruby 2.2.3p146 (2015-07-04 revision 51135) [i386-mingw32]

# retag to something I like
C:\>uru admin tag ruby-2.1 217p376-x32
---> retagged `ruby-2.1` to `217p376-x32`

C:\>uru admin tag ruby-2.2 223p146-x32
---> retagged `ruby-2.2` to `223p146-x32`

C:\>uru ls
    217p376-x32 : ruby 2.1.7p376 (2015-07-03 revision 51128) [i386-mingw32]
    223p146-x32 : ruby 2.2.3p146 (2015-07-04 revision 51135) [i386-mingw32]
  6. Ashley Engelund reporter

    using --dirtag sounds totally reasonable

    Re: making an entry in the wiki -- I'd suggest also an edit of the Examples page: under the "Bulk register all rubies found in subdirs of specified dir (default tag labels)" section, after the example, put a note saying

    "If uru creates duplicate tags (for instance because you have multiple directories of the same version of ruby for different processors (ex: ruby 2.1.5 for i386 and ruby 2.1.5 for x64), use the --dirtag as shown below"

    I think the info should also go on the Examples page because that's what people new to uru will generally read first. Having the info there also communicates that this is expected behavior; having a note only on the Troubleshooting page can communicate that running in to this behavior is a bug/problem.

    Would you like me to edit the wiki (both the example page and the troubleshooting page)? or would you rather do that yourself? (I ask since I have permission & the ability to edit the wiki, but didn't know what you wanted to do with it at this stage.)

  8. Jon repo owner

    New FAQ entry created.

    If you tweak the text, be aware that you need to add two spaces at the end of a sentence but before pressing ENTER to cause line broke sentences that are single spaced. Otherwise markdown thinks the sentences are part of the same paragraph and messes up the formatting.

    For the moment, I've decided to keep uru's default tag behavior as-is and treat this as a documentation issue. Please close this issue when you're OK with the docs. We can always re-open the issue if needed.

  12. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
closed
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!