Should the executable launchers be named as `elixir-ls`

hjpotter92 commented 3 years ago

It is more of a feature request, but the launch script for the language server is named as language_server.bat for windows and language_server.sh for unix, however the readme has just 1 mention of the term language_server (only for the local development section).

This created a confusion, as I installed the project on my arch linux through the AUR package, which generates a linked script /usr/bin/elixir-ls which is what I had expected.

However, when developing within emacs, since elixir-ls was not the default name for the server command, it led to issues..

The name seems intuitive to me, and if the project release also contains for eg. a symlink named as elixir-ls.bat and elixir-ls.sh, it'd really help new developers just setting up lsp integrations.

Cheers

rhblind commented 3 years ago

Yes, I got hit by this one as well, using Emacs. Seems they've changed it in this commit in lsp-mode.

Just symlinking language_server.sh to elixir-ls seems to solve the problem at least for me.

J3RN commented 3 years ago

Luckily for us emacsers, it appears that lsp-mode has reverted that change.

Nevertheless, I did find the setup of the language server to be a bit odd since you have to add a new directory to your $PATH. I wonder at the difficulty of changing the language server to use mix releases, Bakeware, or Lumen to package up the ElixirLS application and place it into somewhere like ~/.bin/elixir-ls, ~/.local/bin/elixir-ls, or even /usr/local/bin/elixir-ls.

Thinking about it further, the mix archive.install command seems to make a task globally available (think mix phx.new) so I wonder if ElixirLS could ship one of these "archives" so that the language server can be started with mix language_server.

axelson commented 3 years ago

I do agree that elixir-ls would be a better binary name than language_server.sh. Regarding releases, bakeware (lumen doesn't make sense since it isn't a complete version of OTP), or an archive, it would be great for someone to explore that. There's a related open issue at https://github.com/elixir-lsp/elixir-ls/issues/115 to improve the packaging approach, so someone digging into that and coming up with a proposal that'll work for all the supported platforms would be great.

J3RN commented 3 years ago

Hey all! I did some research into mix archives and escritps and here are my conclusions:

mix archives, despite my enthusiasm, seem to be a poor fit.

Archives are meant to contain small projects

The language server is hardly small.

archives do not include dependencies, as those would conflict with any dependency in a Mix project after the archive is installed.

I don't really understand the bit about the dependency conflict, but the fact that dependencies aren't included means ElixirLS can't have elixir_sense, jason, etc, which makes mix archives a no-go.
asdf will store mix archives and escripts with their respective Elixir versions, which allows you to have a different version of an archive or escript for each version of Elixir you have installed. Some may complain that this takes up too much space, but I see it as a feature since it allows users to continue to use old versions of the language server with old versions of Elixir and new versions of the language server with newer Elixir versions.
The syntax to install escripts is friendlier than I would have guessed. For intance, mix supports
```
mix escript.install hex hex_package
```
and also
```
mix escript.install github user/project
```
among others.
asdf will add a "shim" (a symlink to ~/.asdf/shims) for each escript installed. That means if you install an escript named language_server, it will be symlinked to ~/.asdf/shims/language_server, and the ~/.asdf/shims directory should already be on your $PATH, so it can be run with
```
$ language_server
```

With all of that taken into consideration, I did an experiment and got the language server working locally as an escript. The downside to this approach is that I can't find any documentation for multiple escripts from a single (here, umbrella) project. For instance, using the GitHub syntax for this repo would be

mix escript.insall github elixir-lsp/elixir-ls

but the mix.exs file at the root of the project can only define one escript, when it should practically have two (the debugger and the language server).

@axelson I saw that you mentioned in #115 that ElixirLS used to be distributed as an escript, but that was changed over some conflict with ASDF. Do we have any further details around that? ASDF and escripts seem to work together pretty well at the moment.

lukaszsamson commented 3 years ago

The solution needs to cover windows as well so asdf is a no go.

J3RN commented 3 years ago

@lukaszsamson asdf isn't a packaging tool or distribution mechanism by itself, I only wanted to say that asdf works well with escripts, which is a packaging tool, format, and distribution system that I think might work well for ElixirLS.

I should have mentioned, though, that escript distribution without asdf means that the user must add ~/.mix/escripts (or wherever escripts are stored on Windows) to their $PATH (or Path on Windows). I hope Homebrew and the official Windows installer do that automatically, but I'll verify.

hjpotter92 commented 3 years ago

I should have mentioned, though, that escript distribution without asdf means that the user must add ~/.mix/escripts (or wherever escripts are stored on Windows) to their $PATH (or Path on Windows).

Don't they have to do the same for current language_server.bat?

J3RN commented 3 years ago

@hjpotter92 Yep, assuming they're not using the VS Code plugin which handles such things. The rest of us (emacsers, vimmers, etc) have to modify our $PATHs anyhow, and adding the escripts directory is more generally useful than a one-off for the language server anyhow.

lukaszsamson commented 3 months ago

Is there a consensus how the launchers should be called?

elixir-lsp / elixir-ls

Should the executable launchers be named as `elixir-ls` #522