-
-
Notifications
You must be signed in to change notification settings - Fork 189
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
auto.fish changes to system ruby when no .ruby-version is present #462
Comments
Yeah I should probably introduce another variable for the "default ruby" (defaults to system) and have Although, you can setup a default ruby of sorts by simply installing a new version into |
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 If we do go the default ruby route, i'd imagine setting the default ruby would be done in the |
The use case here is that I work on a lot of projects with varying Ruby versions set via 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? |
That is a valid concern. Any script or package that uses |
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 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 |
Added some tests, but ran into an interesting edge-case. @todd-a-jacobs what do you think |
@postmodern said:
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
While I think the chruby approach is generally superior, and should keep
Keeping the principle of least surprise in mind, here are my thoughts:
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 As for printing the rubies, the default ruby could be indicated by simply appending |
Whether or not one has a ~/.ruby-version to defined with a default, when I have the following in my ~/.config/fish/config.fish:
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:
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 thanset -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 ofchruby 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 ofchruby 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: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.
The text was updated successfully, but these errors were encountered: