Configure specific elixir and erlang paths/version for a runtime #334
Comments
jjcarstens
added a commit
to jjcarstens/next-ls
that referenced
this issue
Jan 20, 2024
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
added a commit
to jjcarstens/next-ls
that referenced
this issue
Jan 20, 2024
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
mhanberg
added a commit
that referenced
this issue
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
This was referenced Jul 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
There is the use case that you might have a mono repo where each individual project is built on a different Elixir and OTP version. These should be accurately reflected by the runtime that is started for each sub project.
This will most likely be solved with the local config file #287.
The text was updated successfully, but these errors were encountered: