feat(runtime): support workspace shims with elixir_exec option
#360
Conversation
This file contains 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
Relates to elixir-tools#334 IDEs like to work with shims rather than tools that alter path (such as `mise`/`rtx`). As a result, one must launch their IDE manually from a terminal session with all the `PATH` loaded in order to properly find the `elixir` executable. This works fine, but switching between projects/workspaces that have varying Elixir/OTP versions will most likely be using the version loaded when launching the program from terminal. One resolve might be to include shims in the `PATH` globally. However, that negates some of the reasoning to move to alternate tools like `mise. Instead, this allows setting the `elixir_exec` option to point directly at a shim. When used in workspace directories, that should also be able to load the correct versions defined in the tool version files. This also allows keeping the need for a shim isolated to the LS tool rather than global use
jjcarstens
force-pushed
the
manual-elixir-shim
branch
from
87da773
to
8a6101d
Compare
jjcarstens
changed the title
elixir_exec optionelixir_exec option
jjcarstens
changed the title
elixir_exec optionelixir_exec option
|
I think this is semantics, but are you intending to set this to the path of the shim or the path of the actual binary? |
|
It could be either. Personally, I would set to shim because I use I would be something like |
|
Does the shim read from the file or env vars. It's unclear to me if the shim would work still if the editor hasn't inherited the environment. |
|
Shims are usually an executable or small script that's supposed to know how to find and forward to the target. So yes it should. In my little test I had initially cleared the environment and only gave the shim, but that affects the path globally and would break the other tests. Though running individually it seemed to work fine |
mhanberg
added a commit
that referenced
this pull request
Apr 12, 2024
This patch adds support for completion candidates for functions/macros imported via `import`, modules aliases via `alias`, module attributes, and any of the above when injected via a macro such as `use`. However, this is powered by new APIs and compiler changes that will be available in Elixir 1.17, so when completions are enabled, we will use a bundled 1.17 runtime of Elixir, instead of the Elixir in the user's path. This is a tradeoff, but I think one that is worthwhile in the name of progress and improving the language and ecosystem. Once completions exit experimental status, this means that Next LS will always run with a bundled copy of Elixir of Elixir unless the user's local copy is sufficiently new. This can be controlled via a setting. Related #45 Closes #360 Closes #334
1 task
This was referenced Jul 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Relates to #334
IDEs like to work with shims rather than tools that alter path (such as
mise/rtx). As a result, one must launch their IDE manually from a terminal session with all thePATHloaded in order to properly find theelixirexecutable. This works fine, but switching between projects/workspaces that have varying Elixir/OTP versions will most likely be using the version loaded when launching the program from terminal.One resolve might be to include shims in the
PATHglobally. However, that negates some of the reasoning to move to alternate tools like `mise.Instead, this allows setting the
elixir_execoption to point directly at a shim. When used in workspace directories, that should also be able to load the correct versions defined in the tool version files. This also allows keeping the need for a shim isolated to the LS tool rather than global use