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

Allow unprefixed version numbers in .ruby-version #248

Closed
konklone opened this issue Feb 3, 2014 · 9 comments
Closed

Allow unprefixed version numbers in .ruby-version #248

konklone opened this issue Feb 3, 2014 · 9 comments

Comments

@konklone
Copy link

konklone commented Feb 3, 2014

It seems only helpful to allow someone to specify 2.1.0 instead of ruby-2.1.0.

rbenv appears to feel strongly about the bare 2.1.0 convention, and are currently issuing warnings when ruby-2.1.0 is used. They've said they'll drop these warnings if chruby and rvm will accept a 2.1.0 convention and assume a ruby- prefix.

This seems all to the good to me - reduces confusion and enhances consistency.

@postmodern
Copy link
Owner

chruby merely passes the contents of .ruby-version to the chruby function. chruby simply uses fuzzy matching, so the following version strings all work: ruby, 1.9, ruby-1.9, ruby-1.9.3-p484.

chruby and ruby-install both encourages the use of the ruby- prefix, so that chruby 2.1.0 does not accidentally select rubinius-2.1.0 instead of ruby-2.1.0.

@konklone
Copy link
Author

konklone commented Feb 3, 2014

How about having 2.1.0 default to ruby-2.1.0 in case of a tie (if multiple are installed)?

@postmodern
Copy link
Owner

@konklone we could possibly do that, however chruby's selection algorithm is predictable and simple. Simply iterate the $RUBIES array, check for an exact match or a sub-string match, and use the last match.

@konklone
Copy link
Author

konklone commented Feb 3, 2014

Hmm - perhaps the easiest way to do it is to tweak the ordering of $RUBIES such that ruby- prefixed Rubies always end up as the last option. I suspect it would naturally already for the popular options I can think of, but it seems like you'd want a higher guarantee than that.

@postmodern
Copy link
Owner

@konklone users can append arbitrary paths to $RUBIES or override it entirely. This would require sorting $RUBIES each time it is iterated; in such a way that avoids implicit keyword splitting. I posted the question on twitter, so hopefully some actual users will post feedback.

@aprescott
Copy link

If #217 were implemented and RUBIES contained globs, ruby-* could be at the end, which would duplicate the directory entries but would effectively allow ruby-* to take precedence by being at the end.

@aprescott
Copy link

For example:

$ tree
.
├── a
├── b
├── foo-a
├── foo-b
├── foo-x
├── foo-y
├── x
└── y

$ echo {*,foo-*}
a b foo-a foo-b foo-x foo-y x y foo-a foo-b foo-x foo-y

@aprescott
Copy link

@postmodern I think users who are appending paths to RUBIES should be aware that they're changing the precedence anyway, so "your RUBIES will not be sorted" would be reasonable enough, I think.

@postmodern
Copy link
Owner

@aprescott unfortunately me nor @havenwood could not find a way to specify dir globs as Strings and expand them in a for loop, but avoid implicit keyword splitting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants