Easier installation for example with package managers

[auxiliumknowledge]

I know this is a great ask, but it would help distribute this really impressive work. Texlab should be installed and updated within the users ecosystem of tools. This presents three options:

1. Texlab becomes an editor extension specific package (nvim, vscode, emacs)
2. Texlab becomes an system level package (brew, apt, scoop)
3. Texlab becomes part of tex ditributions (texlive, mactex, miktex)

Option one is in every case a bad idea and should be avoided. Option two would leave you with much packaging and is not optimal. Option three should be the goal. Please consider, i don't know how much work lies behind those options. Feel free to ignore my heavy request and thank you for this project.

[clason]

Honest questions, because I don't understand which problem you are trying to solve:

1. Why is option 1 a bad idea? (I don't really see that. If your editor is not on there, is downloading the binary and putting it in the appropriate place really not feasible?)
2. Are you planning on using texlab with multiple editors? (This is when option 2 would make sense.)
3. Are you planning on using texlab outside of an editor? (This is when option 3 would make sense.)
4. Did you see Possible to ship on CTAN? #64? (This is a requirement to get included in texlive, after which it is pretty automatic, I believe.)

In any case, I think the main bottleneck for using texlab in an editor is not getting the binary but configuring the client to talk to the server, and this wouldn't help with it. More useful in my opinion is if people using different editors would share their config on this project's wiki, especially if it's not just "click here to install extension".

[efoerster]

Thanks for your feedback. Our (@pfoerster and me) current sight on this is:

1. We should keep the first option as a fallback method for Windows users. In the VS Code extension we check if texlab is in the PATH and if it is not we ask the user if we should download it.
2. There is already some progress on this. TexLab is currently included in Arch Linux and NixOS Unstable. I would love to see TexLab included by more distributions, however option 3 would make this somewhat redundant.
3. This is the ultimate goal to reach. The user gets all updates of TexLab from the TeX distribution. Possible to ship on CTAN? #64 is the first step for this, but we delayed it because the server relied on Rust Nightly, which is no longer the case now.

@clason:

In any case, I think the main bottleneck for using texlab in an editor is not getting the binary but configuring the client to talk to the server, and this wouldn't help with it. More useful in my opinion is if people using different editors would share their config on this project's wiki, especially if it's not just "click here to install extension".

I agree with this but I think the point here is to improve the update mechanism of TexLab.

[clason]

@efoerster That makes sense, I missed that.

Getting binaries on CTAN is not trivial, and texlive is more difficult still (they require the sources, both because they need to check for open source license and because they compile for all supported platforms). It might make sense to send an email to tex-live@tug.org to ask for guidance.

I can see what's required to get it into homebrew in the mean time.

[clason]

@efoerster Trying to create a homebrew formula and unfortunately running into problems.

1. The citeproc bundling fails for some reason, although cargo build --release works on a separate checkout of the repo (homebrew shouldn't be doing anything else). Do you have some idea why this might be the case? got it working by going back to manually calling npm install && npm run dist

2. Homebrew demands using cargo install --root $PREFIX --path ., but that will create a debug build, right? Actually, that doesn't even build the 1.6.0 release, but it seems to work for HEAD?

3. Homebrew also demands a test. What would be a good (simple) test from the command line to see if texlab built correctly?

[pfoerster]

2. Homebrew demands using cargo install --root $PREFIX --path ., but that will create a debug build, right? Actually, that doesn't even build the 1.6.0 release, but it seems to work for HEAD?

I think, you are missing --locked. This command will create a release build. See https://github.com/Homebrew/homebrew-core/blob/master/Formula/ripgrep.rb#L25 for more information.

3. Homebrew also demands a test. What would be a good (simple) test from the command line to see if texlab built correctly?

You can try executing TexLab and pass the following file via stdin (maybe you need to tweak the content length):

Content-Length: 103

{"jsonrpc": "2.0", "id": 0, "method": "initialize", "params": { "rootUri": null, "capabilities": {}}}

TexLab should then return a message that contains the substring "result" (check it via include?).

[clason]

Thanks, will try that! The build failure on 1.6.0 may be due to the beta version of rust used there -- are you planning on making a 1.6.1 release soon? (Then I would wait and submit that instead of 1.6.0 for stable.)

[pfoerster]

are you planning on making a 1.6.1 release soon?

1.7.0 is on the way 🚀

[clason]

And 1.8.0 is now on homebrew: Homebrew/homebrew-core@6dacca1

[clason]

Just tried to update homebrew to 2.0.0, and the above test fails with

{"jsonrpc":"2.0","error":{"code":-32700,"message":"Could not parse the input"},"id":null}thread 'thread 'tokio-runtime-workermain' panicked at '' panicked at 'initialize has not been calledcalled `Result::unwrap()` on an `Err` value: Kind(InvalidData)', ', src/main.rs/Users/clason/build/texlab/src/server.rs::7684::259

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:70:27

I assume I have to update the input, but I'm not sure how?

[clason]

Nope, just the output changed -- please ignore.

[pfoerster]

Closing this issue, as there is not much to do to improve the packaging situation from our side