Easier installation for example with package managers about texlab HOT 11 CLOSED

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

from texlab.

@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 [email protected] to ask for guidance.

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

from texlab.

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?).

from texlab.

are you planning on making a 1.6.1 release soon?

1.7.0 is on the way 🚀

from texlab.

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 #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".

from texlab.

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

from texlab.

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

from texlab.

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

from texlab.

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?

from texlab.

Nope, just the output changed -- please ignore.

from texlab.

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

from texlab.