Don't require full ruby version info about rvm

[fnichol]

Thanks for bringing this up, @mheffner. Initially, I did an RVM codebase dive to find the version string recognition and it was way more complicated than I expected. Basically a massive hunk of if/elsif constructs. As a result, my quicker-but-stricter implementation is in ruby_string_sane?() and ruby_known?()

When I started this cookbook I was trying to reduce the chances of a failed execution due to invalid user input (i.e. a bad or misspelled ruby string). I've been starting to rethink that position lately, since lots can go wrong in a chef execution given bad attribute metadata.

What do you think the metadata approach should be: a fail-fast (but more inflexible) or the unix chainsaw (anything you want, at your own peril)?

[mheffner]

Personally I'm never a fan of duplicating validation logic, especially if the duplicate could contain bugs or become stale in reference to the canonical version. Therefore, as long as the error message from RVM when a bad ruby name is entered is clear enough, I would not duplicate the validation logic in chef-rvm that RVM is already doing.

[relistan]

+1

[fnichol]

I'm almost finished a refactoring which should support the arbitrary RVM ruby strings that the CLI accepts. I'll update this issue when it's complete for some verification.

[fnichol]

All done now. All resources that use rvm/ruby strings should support all the native RVM string forms like '1.8.7', '1.8.7-p352', 'ree', etc.

All the strings now get "normalized" through a Chef::RVM::StringCache class that uses RVM directly.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.