Keep the environment clean with projects using Docker

[k-neo]

I have checked that this feature is not already implemented

• [X] This feature does not exist

Use case

I'm trying to use this in a Docker environment. I understand that Ruby-lsp utilizes Gemfile to create an environment. However, I am having trouble with the Gemfile.lock used by Docker being changed.

I want to change only .ruby-lsp/Gemfile.lock and not change ./Gemfile.lock directly under the project.

Description

For example, the following changes are made to Gemfile.lock.

    nokogiri (1.14.3-aarch64-linux)
      racc (~> 1.4)
    nokogiri (1.14.3-arm64-darwin)
      racc (~> 1.4)

Implementation

No response

[HolyWalley]

Hi

I'm using nvim (not sure about other editors) and it works for me just to install gem globally (not in gemfile)

however, it does not work with https://github.com/Shopify/ruby-lsp-rails (cause it must be included into rails project to create and endpoint)

[vinistock]

Thank you for the report!

Do you have ruby-lsp in your project's Gemfile?

Bundler shouldn't be changing your top level Gemfile.lock since we run BUNDLE_GEMFILE=/path/to/project/.ruby-lsp/Gemfile bundle install.

[ilude]

Thank you for the report!

Do you have ruby-lsp in your project's Gemfile?

Bundler shouldn't be changing your top level Gemfile.lock since we run BUNDLE_GEMFILE=/path/to/project/.ruby-lsp/Gemfile bundle install.

Yes but your Gemfile includes the following:

eval_gemfile(File.expand_path("../Gemfile", __dir__))

which cause it to go down one level and include any Gemfile that's there (which is most certainly NOT what it should be doing!)

[vinistock]

We include the top level Gemfile so that we know the dependencies of the project. That allows us to automatically index the correct versions of gems used by the project and to identify which formatter the project uses.

As far as I understand it, it's BUNDLE_GEMFILE that dictates which gemfile and lockfile will be considered by Bundler. Evaluating the top level gemfile should not result in top level lockfile changes.

[k-neo]

Thank you for the replies.

Do you have ruby-lsp in your project's Gemfile?

I didn't add it.

So I tried adding ruby-lsp to the Gemfile.

group :development do
  gem 'ruby-lsp', require: false
end

And although it was not necessary, I ran bundle install(with docker-compose) in the Docker environment.

Then I enabled Ruby-lsp, the top-level Gemfile.lock was changed. The following line was added.

    nokogiri (1.14.3-aarch64-linux)
      racc (~> 1.4)
+    nokogiri (1.14.3-arm64-darwin)
+      racc (~> 1.4)

PLATFORMS
  aarch64-linux
+  arm64-darwin-22

Am I doing something wrong?

[ilude]

We include the top level Gemfile so that we know the dependencies of the project. That allows us to automatically index the correct versions of gems used by the project and to identify which formatter the project uses.

As far as I understand it, it's BUNDLE_GEMFILE that dictates which gemfile and lockfile will be considered by Bundler. Evaluating the top level gemfile should not result in top level lockfile changes.

What if the dependencies of the top level Gemfile are for a completely different version of Ruby than what the RubyLSP gem is installing into?

In my case ruby-lsp is trying to include gems from a Rails 5.1 project into a ruby 3.2 environment, which will always fail. I would still like to use a ruby lsp for code navigation which will work fine within the project without RubyLSP having all the dependencies available in its bundle env.

Seems you need a way to disable this "feature" as in many cases it will break things without telling the user that its trying to "help" them when it doesn't need to. Allowing RubyLSP to run rough shot over the users env and include Gemfiles, without their associated lock files, is a very poor design choice and makes this gem incredibly fragile.

Focus on getting RubyLSP to install cleanly and function. Then worry about adding options to help the user include additional code understanding/navigation to their project if they need it.

[vinistock]

What if the dependencies of the top level Gemfile are for a completely different version of Ruby than what the RubyLSP gem is installing into?

@ilude this shouldn't happen. The Ruby LSP always tries to activate the Ruby version being used by the project - exactly because the locked dependencies may not be compatible with other Ruby versions. If that's not happening, then there's some issue going on.

However, that looks like a distinct issue than the one being reported here. Can you open a separate issue and include more information? Things like, what editor you're using, which version manager, how you are running the Ruby LSP, etc.

Am I doing something wrong?

@k-neo it doesn't look like you're doing anything wrong, but I'm still unsure as to why the top level lockfile is modified despite not pointing bundler to it. I'll need to investigate bundler's internals to understand what's happening.

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[vinistock]

We received no more reports of this and when I tried reaching out to the Bundler team they mentioned this was not supposed to happen when running bundle install.

I'm closing it for now, but please let me know if the issue persists.