ruby: Support "binary" settings for Rubocop and Solargraph #15110
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cla-bot
bot
added
the
cla-signed
vitallium
commented
Jul 24, 2024
vitallium
force-pushed
the
vs/ruby-support-binary-settings
branch
from
6017c6b to
1919b36
Compare
Contributor
Author
|
Added documentation about using folder-specific settings and binary settings. |
vitallium
force-pushed
the
vs/ruby-support-binary-settings
branch
from
1919b36 to
5fb2ac0
Compare
Contributor
Author
|
Rebased against the |
vitallium
force-pushed
the
vs/ruby-support-binary-settings
branch
3 times, most recently
from
5fccd3d to
a18d9ed
Compare
Contributor
Author
|
Okay, I think this pull request is ready for review. |
In Ruby world, like in Node.js world, almost all
projects rely on project specific packages (gems) and
their versions. Solargraph and Rubocop gems are usually
installed as project dependencies. Attempting to use
global installation of them fail in most cases due
to incompatible or missing dependencies (gems).
To avoid that, Ruby engineers have the "bundler"
gem that provides the "exec" command. This command
executes the given command in the context of the bundle.
This pull request adds support for pulling the "binary"
settings to use them in starting both LSPs. For instance,
to start the Solargraph gem in the context of the bundler,
the end user must configure the binary settings in the folder-specific
settings file like so:
```json
{
"lsp": {
"solargraph": {
"binary": {
"path": "/Users/vslobodin/Development/festivatica/bin/rubocop"
}
}
}
}
```
The "path" key must be an absolute path to the `binstub` of
the `solargraph` gem. The same applies to the "rubocop" gem.
Side note but it would be awesome to use Zed specific environment
variables to make this a bit easier. For instance, we could use
the `ZED_WORKTREE_ROOT` environment variable:
```json
{
"lsp": {
"solargraph": {
"binary": {
"path": "${ZED_WORKTREE_ROOT}/bin/rubocop"
}
}
}
}
```
But this is out of the scope of this pull request. The code is a bit
messy and repeatable in some places, I am happy to improve it here or
later.
References:
- https://bundler.io/v2.4/man/bundle-exec.1.html
- https://solargraph.org/guides/troubleshooting
- https://bundler.io/v2.5/man/bundle-binstubs.1.html
vitallium
force-pushed
the
vs/ruby-support-binary-settings
branch
from
a18d9ed to
87913ed
Compare
Merged
Contributor
Author
Thank you for making the Ruby extension better than it was! I use that as an opportunity to learn something new. |
maxdeviant
added a commit
that referenced
this pull request
Aug 6, 2024
ruby: Bump extension version to v0.1.0 Why not v0.0.9? I think the Ruby extension is mature, and it's time to release the first minor version. But I am totally OK with changing it to 0.0.9. Included changes: - #15778 - #15762 - #15110 - #15297 Release Notes: - N/A --------- Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
notpeter
pushed a commit
to zed-extensions/ruby
that referenced
this pull request
Oct 11, 2024
…zed#15110) Hello, this pull request adds support for specifying and using the "binary" settings for Rubocop and Solargraph LSPs. AFAIK, Ruby LSP does not require the bundler context but that could be added later easily. In Ruby world, like in Node.js world, almost all projects rely on project specific packages (gems) and their versions. Solargraph and Rubocop gems are usually installed as project dependencies. Attempting to use global installation of them fail in most cases due to incompatible or missing dependencies (gems). To avoid that, Ruby engineers have the `bundler` gem that provides the `exec` command. This command executes the given command in the context of the bundle. This pull request adds support for pulling the `binary` settings to use them in starting both LSPs. For instance, to start the Solargraph gem in the context of the bundler, the end user must configure the binary settings in the folder-specific settings file like so: ```json { "lsp": { "solargraph": { "binary": { "path": "/Users/vslobodin/Development/festivatica/bin/rubocop" } } } } ``` The `path` key must be an absolute path to the `binstub` of the `solargraph` gem. The same applies to the "rubocop" gem. Side note but it would be awesome to use Zed specific environment variables to make this a bit easier. For instance, we could use the `ZED_WORKTREE_ROOT` environment variable: ```json { "lsp": { "solargraph": { "binary": { "path": "${ZED_WORKTREE_ROOT}/bin/rubocop" } } } } ``` But this is out of the scope of this pull request. The code is a bit messy and repeatable in some places, I am happy to improve it here or later. References: - https://bundler.io/v2.4/man/bundle-exec.1.html - https://solargraph.org/guides/troubleshooting - https://bundler.io/v2.5/man/bundle-binstubs.1.html This pull request is based on these two pull requests: - zed-industries/zed#14655 - zed-industries/zed#15001 Closes zed-industries/zed#5109. Release Notes: - N/A --------- Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
notpeter
pushed a commit
to zed-extensions/ruby
that referenced
this pull request
Oct 11, 2024
Bump extension version to v0.1.0 Why not v0.0.9? I think the Ruby extension is mature, and it's time to release the first minor version. But I am totally OK with changing it to 0.0.9. Included changes: - zed-industries/zed#15778 - zed-industries/zed#15762 - zed-industries/zed#15110 - zed-industries/zed#15297 Release Notes: - N/A --------- Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello, this pull request adds support for specifying and using the "binary" settings for Rubocop and Solargraph LSPs. AFAIK, Ruby LSP does not require the bundler context but that could be added later easily.
In Ruby world, like in Node.js world, almost all
projects rely on project specific packages (gems) and their versions. Solargraph and Rubocop gems are usually installed as project dependencies. Attempting to use global installation of them fail in most cases due to incompatible or missing dependencies (gems).
To avoid that, Ruby engineers have the
bundlergem that provides the
execcommand. This command executes the given command in the context of the bundle.This pull request adds support for pulling the
binarysettings to use them in starting both LSPs. For instance, to start the Solargraph gem in the context of the bundler, the end user must configure the binary settings in the folder-specific settings file like so:{ "lsp": { "solargraph": { "binary": { "path": "/Users/vslobodin/Development/festivatica/bin/rubocop" } } } }The
pathkey must be an absolute path to thebinstubof thesolargraphgem. The same applies to the "rubocop" gem. Side note but it would be awesome to use Zed specific environment variables to make this a bit easier. For instance, we could use theZED_WORKTREE_ROOTenvironment variable:{ "lsp": { "solargraph": { "binary": { "path": "${ZED_WORKTREE_ROOT}/bin/rubocop" } } } }But this is out of the scope of this pull request. The code is a bit messy and repeatable in some places, I am happy to improve it here or later.
References:
This pull request is based on these two pull requests:
Closes #5109.
Release Notes: