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

Confusion of default ruby version #186

Closed
eregon opened this issue Jul 26, 2013 · 9 comments
Closed

Confusion of default ruby version #186

eregon opened this issue Jul 26, 2013 · 9 comments

Comments

@eregon
Copy link
Contributor

eregon commented Jul 26, 2013

Admittedly this might not be the optimal setup for chruby, but I would never expect to be so confused from a simple default version setting (the rest seems great though!).

# In .profile
source /usr/local/opt/chruby/share/chruby/chruby.sh
RUBIES=(~/.ry/lib/ry/rubies/*)
chruby 2.0.0-dev

$ ls ~/.ry/lib/ry/rubies/
1.8.7-p371    1.9.3-p125    2.0.0-dev     2.0.0-p0      jruby-1.6.7   jruby-local   macruby       maglev        mri-local     rbx-2.0.0-dev rbx-local

# New terminal:
Last login: Fri Jul 26 12:29:21 on ttys018
Using rbx-1.8.7
~ ∴ chruby
   1.8.7-p371
   1.9.3-p125
   2.0.0-dev
   2.0.0-p0
   jruby-1.6.7
   jruby-local
   macruby
   maglev
   mri-local
 * rbx-2.0.0-dev
   rbx-local
~ ∴ ruby -v
rubinius 2.0.0dev (1.8.7 a3c316b1 yyyy-mm-dd JI) [x86_64-apple-darwin10.8.0]

So I get rbx-2.0.0-dev instead of wanted (MRI) 2.0.0-dev (but that is a substring so fuzzy matching picks the wrong one in this case, might be ok, might not, I think exact match should precede fuzzy matching).

And it reports Using rbx-1.8.7 which is definitely confusing to me (I thought it was MRI system 1.8.7 or so at first sight. I guess this is rbx-2.0.0-dev saying it has a RUBY_VERSION of 1.8.7, definitely not very useful to me I would much prefer the rbx version).

Also problematic for multiple versions of 2.0:

~ ∴ chruby 2.0.0-dev
Using ruby-2.0.0
~ ∴ chruby 2.0.0-p0
Using ruby-2.0.0

But that is unsupported I guess.

About the "Using ..." message I would find it much more useful to be the output of ruby -v (or equivalently RUBY_DESCRIPTION). That is usually a bit long, an alternative could be: "$ENGINE $ENGINEVERSION ($RUBYVERSION)" (maybe simply "$ENGINE $RUBYVERSION" for MRI): jruby 1.6.7 (1.9.3p392), ruby 2.0.0p0, rbx 2.0.0.rc1 (1.9.3).

I personally sometimes like to not have my GEM_PATH/GEM_HOME altered (OTOH it is useful to reuse gems in an upgraded compatible version), especially on custom built/dev installations (so multiple versions of 2.0.0 can be supported with no gem inference), yet having gem binaries in PATH (the directory could be created from the proposed version string above and no conflict would occur).

Nitpicking but I do not like much the two calls to find at the top of the script, I'd much prefer it did not look anywhere else if I supply $RUBIES.

My final remark is about the time it takes to switch to jruby (due to evaluation of a little ruby script). I agree the little script is a good way to ensure everything is right and not set anything blindly, but as chruby is "by shell", doing a couple chruby jruby (so all concerned terminals use the desired ruby) might take a while. I guess some caching could be useful here but it would obviously complicate significantly the logic (is there some plugin or so for that you are aware of?).

Sorry for the big first impression dump, but I would like to discuss on this and see what can be solved. I tried chruby a couple months ago and had a very similar impression (therefore decided to retry a couple after that is today).

@havenwood
Copy link
Collaborator

@eregon Updating to the latest release of chruby (v0.3.6) will fix the Using ... output issues since chruby_use no longer echoes the selected Ruby.

@eregon
Copy link
Contributor Author

eregon commented Jul 26, 2013

Indeed, I was using 0.3.5. I think it was useful to have the version with an interactive change, to confirm fuzzy matching worked as expected. But thanks, that is probably less confusing than it was.

@havenwood
Copy link
Collaborator

@eregon A convention we've adopted to help distinguish between Rubinius and Ruby is to name Rubies directories by name-version. See this Issue for the rationale.

So ruby-2.0.0-p247 lets a .ruby-version of 'ruby-2.0.0' be unambiguous, but yeah an issue for existing ry/rbenv installs of ruby without a ruby- prefix.

@havenwood
Copy link
Collaborator

Just an aside, but jruby-launcher might help make the JRuby launch time more bearable (if you're not already using it): chruby-exec jruby -- gem install jruby-launcher.

@eregon
Copy link
Contributor Author

eregon commented Jul 26, 2013

I see. Unfortunately I cannot just rename the directory (could symlink everything from some other dir though).
Typing ruby-2 is relatively long, I guess I'll have to find a shorter mnemonic abbreviation.

Yeah, already using jruby-launcher. Maybe some Nailgun / drip could help.

@zendeavor
Copy link

fuzzy matching doesn't pick the "wrong one." it picks the last one. there is no fair way to choose which match is used; either it's the first && break from the matcher loop or it's the last and run the complete matcher loop every time. I have devised a way to do this without looping, but it's a work-in-progress and uses an admittedly strange technique that may be hard to read or maintain.

As for which RUBIES element is at what index in the array, well, that's a tough thing to nail down. the initial problem is really that globs are sorted (may or may not be influenced by collation settings) and this cannot be turned off. since every shell sorts the glob before populating the RUBIES array, then you can't rely on the behaviour to put your preferred ruby later or earlier. one workaround that you can use is to rename your rubies' directories such that they collate sort in the order you prefer (such that your preferred ambiguous ruby is sorted last by the shell globbing mechanism, you could prefix rubies with an index like 000-ruby-1.9.3-p448.) it's ugly, and time-consuming, and you have to remember to redo it later, and if you change your mind, renaming all of them to force a different sort order is a pain.

as an alternative, you can populate the array manually without using a glob. chruby does not do anything to sort the array (and it should not ever) so if you add your rubies to the array in manually indexed order, then there is no issue with glob sort ordering. it's a little more manual than we'd probably like, but it avoids the problem completely and allows you to specify manual indexing, which forces chruby to match your preferred ruby by default (as long as you remember that chruby chooses the latest indexed match and set this up accordingly)

as an aside, it should be noted that chruby cannot effectively honor that the RUBIES array has already been populated; instead, you are encouraged to populate it after sourcing chruby. the same goes for every other script that you ever source in your dotfiles or scripts. it is wrong to set things up and then source somescript afterwards because somescript may be setting some defaults or initial values and probably won't restore your values afterwards. chruby does the same; it empties the RUBIES array, and then populates it with the defaults.

@zendeavor
Copy link

@eregon if you are hip with the modern crowd, you can use tmux to multiplex a command over many open shells; it requires a little futzing on your end, and i can't guarantee that it'll be any easier than the current method of invoking chruby manually for every open shell. have a look at the synchronize-panes setting if it strikes your fancy.

there are other valid solutions as well, but this is impossible to solve in chruby as we can't affect the process environment of other shells.

@havenwood
Copy link
Collaborator

Closing. As previously mentioned, with the release of 0.3.6 the Using ... issue was resolved due to no longer echoing current Ruby. And the order of the RUBIES array is determined by glob or can be customized as @zendeavor details above.

@eregon
Copy link
Contributor Author

eregon commented Aug 17, 2013

@zendeavor as an aside, it should be noted that chruby cannot effectively honor that the RUBIES array has already been populated; instead, you are encouraged to populate it after sourcing chruby. the same goes for every other script that you ever source in your dotfiles or scripts. it is wrong to set things up and then source somescript afterwards because somescript may be setting some defaults or initial values and probably won't restore your values afterwards. chruby does the same; it empties the RUBIES array, and then populates it with the defaults.

I would see RUBIES as an input variable (as well as output too here), so I would find logical to set it to a relevant value before the script, let it run, and set it to whatever it likes.

@havenwood Closing. As previously mentioned, with the release of 0.3.6 the Using ... issue was resolved due to no longer echoing current Ruby. And the order of the RUBIES array is determined by glob or can be customized as @zendeavor details above.

OK, I'll report the remaining issue separately: forced gem location.
I still think the current fuzzy matching technique is not optimal because of the choice of no completion and the renaming needed.

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

No branches or pull requests

3 participants