Improve chruby handling for missing .ruby-version and missing Ruby installations
#2793
Labels
enhancement
New feature or request
vscode
This pull request should be included in the VS Code extension's release notes
Comments
vinistock
added
enhancement
This was referenced Nov 6, 2024
|
Don't mean to hijack here, but I wanted to raise awareness as to push for this issue. I'm using sublime text 4 and chruby. I simply cannot get According to the docs, the setup should simply work out of the box. As I said, I cannot see where ruby-lsp is getting it's ruby version from. |
|
This issue is related to our chruby integration for the VS Code extension, which you can't use in Sublime. Since you already created a separate issue for Sublime, let's centralize the discussions there. |
vinistock
added a commit
that referenced
this issue
Nov 20, 2024
…2835) ### Motivation First step for #2793 This PR passes down the `manuallySelectRuby` function to version managers in order to allow specific version managers to offer configuring fallbacks under certain situations. ### Implementation This PR only starts passing the function down to managers. The next PR in the stack starts using it. ### Automated Tests Updated existing tests.
vinistock
added a commit
that referenced
this issue
Nov 22, 2024
### Motivation Completes a significant part of handling missing `.ruby-version` for #2793 If the user doesn't have a `.ruby-version` in their project or in any parent directories, then we can try to fallback to the latest known Ruby available. **Note**: this PR doesn't handle the aspect of having a `.ruby-version` configured to a Ruby that's not installed. I'll follow up with that later. ### Implementation To avoid having this behaviour be surprising, I used a progress notification with a 5 second delay warning the user that we are going to try falling back to the latest known Ruby. If they don't do anything, we search for the Ruby installation and launch. If the user clicks cancel, then we stop everything and offer them 3 options: 1. Create a `.ruby-version` file in a parent directory. Here we use a quick pick to list all known rubies and create the file for them using what they select 2. Manually configure a global fallback Ruby installation for the LSP 3. Shutdown ### Automated Tests Added automated tests for two scenarios. I haven't figured out if it's possible to trigger the cancellation in a test even with a stub, so I failed to create tests for those cases. If you have an idea about how to fake the cancellation of the progress notification, please let me know!
vinistock
added a commit
that referenced
this issue
Nov 29, 2024
…uested version (#2912) ### Motivation Closes #2793 This PR starts adds a fallback for when the specified Ruby in `.ruby-version` is not found/not installed. The UX is similar to the fallback for missing `.ruby-version` configurations. We show a temporary progress warning the user we're going to fallback and give the chance of cancelling, which allows them to manually configure the right version. ### Implementation The implementation is very similar to the fallback for missing `.ruby-version`. The main distinction is that, when we know the version specified, we can try to fallback to the closest one available. There are a few decisions I baked into the implementation: 1. We do not try to approximate major versions. For example, if the `.ruby-version` file specifies Ruby 4.0.0, we would not try to fallback to 3.0.0. I think this is a fair limitation and since Ruby is so conservative about major versions, it shouldn't be too painful 2. To approximate, we search for the Ruby installation with the smallest difference in minor version using the highest patch version as the tie breaker (this is done with a sort). For example, if the requested version is `3.3.5` and we have `3.1.0` and `3.2.2` installed, we want to pick `3.2.2` because that's closest to `3.3.5`. And as another example, if both `3.2.0` and `3.2.2` are installed, we would pick `3.2.2` because that's the highest patch ### Automated Tests Added tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are some corner cases for our chruby integration that aren't very user friendly at the moment.
Missing .ruby-version file
There are two ways to define a "global" Ruby version with chruby. The first one is to set the version via a shellscript, which doesn't do anything in the editor since the NodeJS process running the extension is not sourcing those files. It only impacts the terminal.
The second one is to define a
.ruby-versionin a parent directory. Chruby goes up directories trying to find a.ruby-versionfile. I had assumed that this was quite common and the standard way of using chruby, but based on our telemetry this is clearly not the case.The question then becomes what to do if we can't find a
.ruby-versionin any of the parent directories. We can try to launch with whatever is the latest Ruby installed, but that may conflict with the Ruby constraints defined in theGemfile, which will fail to launch the language server. We could first check if the Gemfile has that constraint, but that may also mean having to parse the constraints ourselves (e.g.:ruby "~> 3.1").We can also try to better explain that adding a
.ruby-versionin parent directories serves as the fallback, but that will still require manual intervention from the user, even if it's just clicking a button to create the new file.Whatever we end up deciding here, it's really important to show in the UI what happened, so that it's clear why the LSP is running with a specific Ruby version.
Missing rubies
The second part of the problem is when there is a
.ruby-versionfile, but the version specified is not installed. This is in part related to #2173.We could also try to launch with an alternative Ruby, but we face similar limitations as the ones described previously with Gemfile constraints.
We also don't know how to install rubies for
chrubysince the tool doesn't come with Ruby installation. People can use whatever they want to install Ruby (Homebrew, ruby-install, ruby-build) and then usechrubyonly for switching versions, which limits what we can offer as part of the experience here.It might be possible, although a higher maintenance cost, to introduce integration with Ruby installers in addition to version "switchers". That way, for tools like
chrubythat only support switching versions, we can try to discover what the user has available to install rubies and offer to use that.The text was updated successfully, but these errors were encountered: