auto.fish changes to system ruby when no .ruby-version is present about chruby HOT 11 OPEN

I do know that Debian and RedHat based Linux distros are very careful about their packages relying on an explicit ruby via #!/usr/bin/ruby to prevent this from happening.

This is yet another reason to never set GEM_HOME btw. Otherwise such scripts would be broken if they use any gem.

from chruby.

Yeah I should probably introduce another variable for the "default ruby" (defaults to system) and have chruby_auto reset back to the default ruby as opposed to system ruby.

Although, you can setup a default ruby of sorts by simply installing a new version into /usr/local. However, that ruby would not be set by chruby, so gems would be installed into /usr/local/share/gems/ by default, as opposed to ~/.gem/ruby/... which chruby uses.

from chruby.

Before we brainstorm how this feature should work, I'm curious what's wrong with just installing the desired default ruby version into /usr/local as the new system ruby?

The use case here is that I work on a lot of projects with varying Ruby versions set via .ruby-version. The problem I'm experiencing is the surprise of not having my default Ruby when I cd to /tmp or some other system directory, and the cognitive load of having to remember that I need to manually chruby "$some_non_system_ruby" whenever I move to a non-project directory.

I'm not looking to change the system Ruby, because that sometimes breaks things. I'm just experiencing a constant stream of "Oh, right; I need to chruby again!" when I switch to /tmp or ~/bin or whatever from a project directory to test something or run a one-liner. In Bash (I'm not sure about Fish) I could certainly leverage PROMPT_COMMAND or similar to roll my own, but it seemed like something that was bound to surprise other people too, whether or not they take the trouble to report it. Users often don't, in my personal experience, unless it's a show-stopper for them.

So, for me it's less about GEM_HOME than it is about resetting the current Ruby version in a way that is unexpected when I'm hopping around the filesystem. Does that add some useful context?

from chruby.

@postmodern said:

Added some tests, but ran into an interesting edge-case. @todd-a-jacobs what do you think chruby --default with no argument should do? Print an error? Print the current default ruby? Unset the default ruby?

That really is an interesting edge case. My initial thought is that a flag with no argument should probably be a request for information, e.g. almost the same as calling chruby with no arguments, except perhaps with a different sigil to mark the current and default rubies. While it's got its own issues, rvm does something similar by using:

# => - current
# =* - current && default
#  * - default

While I think the chruby approach is generally superior, and should keep * to mark the current Ruby, the reason I think we might want to differentiate here rather than taking an action or treating it as an error is that what we're really asking when we discuss an argument-less --default flag is the following pair of questions:

• What's the user's likely intent?
• What is least likely to create unexpected or surprising behavior for the user?

Keeping the principle of least surprise in mind, here are my thoughts:

1. If we treat --default with no argument as a duplicate of -h, it doesn't really add anything to the user's knowledge of chruby state. It just makes them re-run the command, and possibly other commands beforehand to see what the current and default rubies are.
2. If we treat it as a request to set the current Ruby as the default Ruby, that could lead to unexpected surprises if the user has lost track of where they are, or what the current Ruby is (esp. if it's been unintentionally unset or auto-set to the system Ruby).
3. Treating it as a request to switch from the current Ruby to the default Ruby is definitely a legitimate choice, but I think it could lead to the same set of surprises as option 1 and option 2.

In summary, I think treating it as a call to chruby that lists the current and default rubies (assuming chruby itself doesn't yet make that distinction when listing rubies) is sane, safe, and relatively unsurprising. If you think it useful to append the usage instructions for the flag as well then that might add informational value, but I think the central notion of making the flag informational if not passed an argument is probably the best overall solution.

Thoughts?

from chruby.

I've decided that chruby --default "" should probably print an error, otherwise if someone put chruby --default $var in their ~/.bashrc and var is not set, that would be confusing and should be caught.

As for printing the rubies, the default ruby could be indicated by simply appending (default) after the ruby name.

from chruby.

Yeah I should probably introduce another variable for the "default ruby" (defaults to system) and have chruby_auto reset back to the default ruby as opposed to system ruby.

I most definitely prefer the first option. If you're open to the idea, I would be willing to take a stab at a PR for the feature if you don't get to it first. I'm unfamiliar with the code base, though, and would like to know how to ensure I don't introduce any regressions.

from chruby.

Before we brainstorm how this feature should work, I'm curious what's wrong with just installing the desired default ruby version into /usr/local as the new system ruby? Installing gems might be a problem as the default gem home is /usr/local/share/gems/... which requires sudo access. What if chruby could use system ruby, but also set GEM_HOME so that gem install wouldn't require sudo access to write into /usr/local/share/gems/... and instead install into ~/.gem/? See issue #421 where I brainstormed mixing system ruby but with a default GEM_HOME for non-root users.

If we do go the default ruby route, i'd imagine setting the default ruby would be done in the chruby.sh config via a chruby --default <ruby> command. This would set an internal variable DEFAULT_RUBY. chruby_auto would then use DEFAULT_RUBY when resetting the ruby version (would fallback to system if not set, or maybe just call chruby_reset directly).

from chruby.

I'm not looking to change the system Ruby, because that sometimes breaks things.

That is a valid concern. Any script or package that uses #!/usr/bin/env ruby could potentially break if you installed ruby 3.x into /usr/local and the scripts/packages expected ruby 2.x. I do know that Debian and RedHat based Linux distros are very careful about their packages relying on an explicit ruby via #!/usr/bin/ruby to prevent this from happening.

from chruby.

@todd-a-jacobs feel free to try implementing this based on our discussion. I'd recommend branching off the 0.4.0 branch. Take note of chruby_auto_test.sh and how I'm testing chruby_auto. It should be possible to add a test where you set a default ruby, then invoke chruby_auto inside and outside of an auto-versioned directory, and test that the current ruby is reverted correctly.

from chruby.

I forgot that there is already a branch where I experimented with adding chruby --default ... and chruby default. Checkout 9682bfa. Still needs some tests, but it seems to satisfy the requirements. Will probably end up merging it into the 0.4.0 branch.

from chruby.

Added some tests, but ran into an interesting edge-case. @todd-a-jacobs what do you think chruby --default with no argument should do? Print an error? Print the current default ruby? Unset the default ruby?

from chruby.