Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't require full ruby version info #29

Closed
mheffner opened this issue Jul 21, 2011 · 6 comments
Closed

Don't require full ruby version info #29

mheffner opened this issue Jul 21, 2011 · 6 comments
Assignees

Comments

@mheffner
Copy link

When I don't explicitly set the ruby version info like:

      "rubies": [
        "jruby"
      ],

It outputs the following warning and doesn't install the ruby:

WARN: rvm_ruby[jruby] is either not fully qualified or not known . Uservm list knownto get a full list.

It appears you must explicitly set the version number. This works:

      "rubies": [
        "jruby-1.6.3"
      ],

It would be handy to be able to reference the ruby without version number and let rvm default to the most recent version -- what rvm install jruby would do.

@fnichol
Copy link
Contributor

fnichol commented Jul 30, 2011

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
Copy link
Author

mheffner commented Aug 1, 2011

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
Copy link
Contributor

relistan commented Aug 3, 2011

+1

@fnichol
Copy link
Contributor

fnichol commented Aug 8, 2011

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.

@ghost ghost assigned fnichol Aug 8, 2011
@fnichol
Copy link
Contributor

fnichol commented Aug 9, 2011

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.

@fnichol fnichol closed this as completed Aug 9, 2011
@lock
Copy link

lock bot commented Apr 25, 2020

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.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants