auto.fish changes to system ruby when no .ruby-version is present

Whether or not one has a ~/.ruby-version to defined with a default, when I have the following in my ~/.config/fish/config.fish:

source /usr/local/share/chruby/chruby.fish
source /usr/local/share/chruby/auto.fish
chruby 3.0.2

then I correctly have 3.0.2 in my home directory, and get whatever version is specified in a project directory with a .ruby-version. However, if I change to a directory without a .ruby-version chruby_auto just sets me back to the system ruby. For example:

# new shell; expected behavior
~> chruby
   jruby-9.2.14.0
   ruby-2.7.2
   ruby-3.0.0
   ruby-3.0.1
 * ruby-3.0.2

~> printenv | egrep '(CH)?RUBY_'
RUBY_CONFIGURE_OPTS=--with-openssl-dir="/usr/local/opt/openssl@1.1"
CHRUBY_VERSION=0.3.9
CHRUBY_FISH_VERSION=0.8.2
RUBY_VERSION=3.0.2
RUBY_ROOT=/Users/tjacobs/.rubies/ruby-3.0.2
RUBY_AUTO_VERSION=3.0.2
RUBY_ENGINE=ruby

# directory without .ruby-version; unexpected behavior
~> cd /tmp

~> printenv | egrep '(CH)?RUBY_'
RUBY_CONFIGURE_OPTS=--with-openssl-dir="/usr/local/opt/openssl@1.1"
CHRUBY_FISH_VERSION=0.8.2
CHRUBY_VERSION=0.3.9
RUBY_AUTO_VERSION=

~> chruby
   jruby-9.2.14.0
   ruby-2.7.2
   ruby-3.0.0
   ruby-3.0.1
   ruby-3.0.2

If you try cd /tmp; and printenv | egrep '(CH)?RUBY_' it looks like it works, but it's transient success because fish appears to be reporting the environment variables before the Ruby change is completed. If you cd and then check, the Ruby has definitely been reset to the system Ruby.

From a user point of view, it looks like when auto.fish unsets RUBY_AUTO_VERSION, it loses track of whatever the default was supposed to be. When I set a default using chruby or a .ruby-version in my home directory, my expectation is that Ruby will be my default unless overridden by a project .ruby-version.

Looking at the source, auto.fish and chruby.fish use set -gx rather than set -lx for a lot of things, which may be part of the problem since -g affects all shells rather than just the current one. That aside, though, it seems that there's nothing that resets chruby to the initial value of chruby use or checks the ~/.ruby-version when leaving a project directory. This may be by design, but it feels like a bug.

A potential solution might be to have a set -Ux RUBY_AUTO_VERSION_DEFAULT (or maybe just a CHRUBY_DEFAULT_RUBY) set by the first use of chruby use or an encounter with ~/.ruby-version, and then fall back to that when needed. Alternatively, if the user has a .ruby-version in the home directory, then the following makes more sense to me (and is probably less complicated). For example:

set -q RUBY_AUTO_VERSION; or set -lx RUBY_AUTO_VERSION=(cat ~/.ruby-version)

There may be problems with these particular approaches that I haven't thought of; I'm simply offering them as possible solutions if there isn't a better one. The issue may not even be fish-specific (it seems to exhibit the same behavior with Bash on my system, too), but I still find the behavior surprising.

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.

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.

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).

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?

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.

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.

@todd-a-jacobs

@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.

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.

@todd-a-jacobs

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?

@postmodern

@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:

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.
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).
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?

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.

Navigation Menu

Repository navigation

auto.fish changes to system ruby when no .ruby-version is present #462

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

auto.fish changes to system ruby when no .ruby-version is present #462

Description

Activity

postmodern commented on Sep 14, 2021

todd-a-jacobs commented on Sep 14, 2021

postmodern commented on Sep 29, 2021

todd-a-jacobs commented on Sep 30, 2021

postmodern commented on Oct 2, 2021

eregon commented on Oct 3, 2021

postmodern commented on Oct 9, 2021

postmodern commented on Nov 8, 2021

postmodern commented on Nov 8, 2021

todd-a-jacobs commented on Nov 10, 2021

postmodern commented on Dec 1, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions