Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(runtime): support workspace shims with elixir_exec option #360

Closed
wants to merge 1 commit into from

Conversation

jjcarstens
Copy link
Contributor

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 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

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 jjcarstens changed the title Support workspace/project shims with elixir_exec option feat(runtime): Support workspace shims with elixir_exec option Jan 20, 2024
@jjcarstens jjcarstens changed the title feat(runtime): Support workspace shims with elixir_exec option feat(runtime): support workspace shims with elixir_exec option Jan 20, 2024
@mhanberg
Copy link
Collaborator

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?

@jjcarstens
Copy link
Contributor Author

jjcarstens commented Jan 20, 2024

It could be either. Personally, I would set to shim because I use mise and that is static. The shim does evaluation of which elixir version to use and where it is located.

I would be something like ~/.mise/shims/elixir

@mhanberg
Copy link
Collaborator

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.

@jjcarstens
Copy link
Contributor Author

jjcarstens commented Jan 20, 2024

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants