Add docker compose as a version manager

[d-lebed]

Motivation

Many developers working on complex projects rely on Docker Compose to set up their development environments. However, it is not always feasible to use VS Code Dev Containers due to their limited functionality and lack of compatibility with custom workflows. To address this limitation, I have implemented a Docker Compose version manager for the Ruby LSP VS Code extension. This change allows developers to use the LSP server seamlessly within their existing Docker Compose setups, including setups enhanced with tools like Mutagen or even "dip". This change aims to improve compatibility and flexibility for developers using diverse development environments.

This change should also solve #2223

Implementation

I had to make several significant changes:

• Process Execution: To retrieve Ruby information, I replaced the use of exec with spawn, passing a script for execution. This change was made to avoid issues with escaping and to address various problems with container entrypoint implementations.

• Enhanced Manager Functionality: Since commands like bundle install, Rails generators, and others need to be executed inside Docker Compose, the manager object now has expanded functionality and is available within the Ruby class.

• URI Converters: I implemented uriConverters methods (code2Protocol and protocol2Code) to map paths between the local file system and the container. I also applied the converter logic in relevant parts of the code that I was able to identify.

• Docker Compose Configuration Parsing: I added automatic parsing of the Docker Compose configuration. Initially, path mapping was intended to be configured manually, but I found it straightforward to extract this information from the configuration itself.

  • Bonus Features:
    • Added the ability to select a Docker Compose service via the UI and save it in Workspace settings.
    • Included parsing for Mutagen configurations, which is particularly useful for environments running on remote servers.

I did not check the Sorbet extension or others that rely on process.env. They will not work, obviously.

Automated Tests

I updated all the existing tests and added a couple of new ones. If the proposed changes are approved, I will add sufficient new tests to cover the new functionality.

Manual Tests

I tested the extension locally on macOS using both Docker Compose and Mutagen Compose. Additionally, I verified compatibility with rvm and shadowenv.

To test the functionality, you can use a similar docker-compose.yml configuration:

services:
  backend:
    build:
      context: "."
    volumes:
      - .:/app
      - bundle:/usr/local/bundle

volumes:
  bundle:

x-mutagen:
  sync:  
    bundle:
      alpha: "volume://bundle"
      beta: "../bundle/myapp"
      mode: "one-way-replica"

[d-lebed]

I have signed the CLA!

[d-lebed]

Well, perhaps the proposed changes are too significant. I came to this conclusion after noticing this pull request ;)
I reverted the activation of the existing version managers to the previous state, and moved the spawn into the Compose implementation.

[andyw8]

👋 Hi @d-lebed,

I'm not a Docker user, but my understanding is that Ruby LSP is already usable with it via the approach described here:

https://github.com/Shopify/ruby-lsp/tree/main/vscode#developing-on-containers

Have you tried that?

[d-lebed]

Hello, @andyw8. Sure, we've tried this. But unfortunately limitations VSCode adds when using dev containers approach make this unusable for us (and many other developers I believe). For example some other VSCode extensions does not work in dev containers modes, it requires complex configuration for services and networks if you need more then just MySQL and Redis, and so on.

[d-lebed]

@andyw8, @vinistock, I can actually propose an alternative solution that eliminates the need for path mapping in the VSCode extension: adding path mapping support directly to ruby-lsp. This would be similar to the functionality in the debug gem, where you can specify ⁠RUBY_DEBUG_LOCAL_FS_MAP. Implementing this feature would enable users who utilize alternative IDEs like Sublime, Zed, Vim and others, along with a containerized approach, to use ruby-lsp without having to install Ruby and other project dependencies locally.