Support `rv` as a version manager.

[lgarron]

I have checked that this feature is not already implemented

• This feature does not exist

Use case

I'd like to use Ruby LSP with https://rv.dev/

Description

Support rv.

Implementation

No response

[vinistock]

Thanks for the request. We don't have bandwidth at the moment to work on this, but we'll review/accept PRs.

It should be an implementation pretty similar to Mise or even rbenv. As long as there's a way to run our activation script with the correct environment (e.g.: rv exec ruby or something), it should work as expected.

If someone picks this up, please don't hesitate to ask for help if needed.

[matheuscumpian]

Hi @vinistock , I've been using rv for a while so I tried to add a simple support, it would be great to have your review

One thing is that this implementation that I've done in #3878 draft is that its requires rv versions >= 0.3.1 because we rely in a feature that does an auto-discovery of the ruby version to use from .ruby-version or .tool-versions files during rv ruby run. Well, that was the simplest way to run the activation script, but another option is to read the versions from files and run the command with the pinned version, with this we can add support for older versions.

[lgarron]

Hi @vinistock , I've been using rv for a wile so I tried to add a simple support, it would be great to have your review

One thing is that this implementation that I've done in #3878 draft is that its requires rv versions >= 0.3.1 because we rely in a feature that does an auto-discovery of the ruby version to use from .ruby-version or .tool-versions files during rv ruby run. Well, that was the simplest way to run the activation script, but another option is to read the versions from files and run the command with the pinned version, with this we can add support for older versions.

Oooh, glad to see it!

Does the auto-discovery work if .ruby-version or .tool-versions is inside a nested folder? I specifically need this for a project where all the Ruby code is inside a nested folder rather than at the top level of the project/repo/workspace.

[matheuscumpian]

Hi @lgarron, good point, thanks for bringing up this use case. I looked into the uv code, and here's what's happening: we try to find a file starting from the current directory and traversing up to the filesystem root. Something like this:

  loop {
      // Check current directory for version files
      if ruby_version.exists() { /* found it */ }
      if tools_versions.exists() { /* found it */ }

      // Move to parent
      if let Some(parent_dir) = project_dir.parent() {
          project_dir = parent_dir.to_owned();
      } else {
          return Ok(None); // Reached the top
      }
  }

I think that this does not solves your problem, does it?

[lgarron]

I think that this does not solves your problem, does it?

Not at all, unfortunately. That seems to handle the case where the project dir is a sub-directory of the Ruby project directory, not the other way around.

[matheuscumpian]

@vinistock Do the other version managers inside LSP have support for auto-discovery of version files inside nested folders? I'm trying to think if it's worth building a custom version discovery for the LSP or if it would be better to keep the default behavior of rv.

[davidcelis]

Do any version managers (at least the ones with Ruby support) search through child directories for a .ruby-version or .tool-versions file? I’ve only ever seen them do the standard parent directory search.

[lgarron]

@vinistock Do the other version managers inside LSP have support for auto-discovery of version files inside nested folders? I'm trying to think if it's worth building a custom version discovery for the LSP or if it would be better to keep the default behavior of rv.

Do any version managers (at least the ones with Ruby support) search through child directories for a .ruby-version or .tool-versions file? I’ve only ever seen them do the standard parent directory search.

No idea. All I know is that I don't have to worry about this for other languages in VS Code. For example, it doesn't matter if the nearest package.json or tsconfig.json is in a nested folder — I can just open a TypeScript file and the LSP works as I would expect.

[matheuscumpian]

@davidcelis I haven't seen this behavior in other Ruby version managers either.

@lgarron I think this is cool behavior, but if other version managers inside LSP don't support it either, I think we can proceed with the default rv behavior for this initial implementation and create an issue to discuss nested folder version file discovery. What do you think?

[lgarron]

@lgarron I think this is cool behavior, but if other version managers inside LSP don't support it either, I think we can proceed with the default rv behavior for this initial implementation and create an issue to discuss nested folder version file discovery. What do you think?

I guess. I'll file an issue.

EDIT: filed at #3895