Stream: t-compiler/wg-rls-2.0

Topic: cargo install


Igor Matuszewski (Apr 30 2020 at 16:04, on Zulip):

@matklad Hey, so I'm slowly digging into integrating the rust-analyzer into the vscode and been wondering about the current distribution

Igor Matuszewski (Apr 30 2020 at 16:05, on Zulip):

Looking at the current infrastructure, it seems to be very tied to the current extension and installing it alongside of it

Igor Matuszewski (Apr 30 2020 at 16:06, on Zulip):

Apart from providing the best experience coupled with a dedicated plugin, is there any other technical reason not to support a regular cargo install means of distribution?

Igor Matuszewski (Apr 30 2020 at 16:06, on Zulip):

Is it because we'd like to continue providing rolling releases without the semver hassle?

matklad (Apr 30 2020 at 16:13, on Zulip):

So, cargo install is supported

matklad (Apr 30 2020 at 16:13, on Zulip):

or rather, it just works

matklad (Apr 30 2020 at 16:13, on Zulip):

(with --git=...

matklad (Apr 30 2020 at 16:14, on Zulip):

But it's kind of unpleasant, as it builds stuff from source. Not that building rust-analyzer is hard (we have zero c deps, which is even checked on CI), but it's not super fast

matklad (Apr 30 2020 at 16:15, on Zulip):

Like, if cargo install could do binary packages, we'd do that

Igor Matuszewski (Apr 30 2020 at 16:16, on Zulip):

ah right, I missed that

matklad (Apr 30 2020 at 16:17, on Zulip):

I wouldn't call that the infra is reallied tied to the extension.

Publishing-wise, we just ship binaries to GH releases.

On the extension side, we basically need just a path to the rust-analyzer executable. But we also implement "download from github" thing

Igor Matuszewski (Apr 30 2020 at 16:17, on Zulip):

I was scouring the code and referred to the cargo xtask install ra

Igor Matuszewski (Apr 30 2020 at 16:17, on Zulip):

which does a lot of vscode checking and tweaking, hence my original comment

matklad (Apr 30 2020 at 16:18, on Zulip):

Yeah, cargo xtask install installs both the binary and the vscode extension

Igor Matuszewski (Apr 30 2020 at 16:18, on Zulip):

I imagine the alternative is to download the release directly from https://github.com/rust-analyzer/rust-analyzer/releases/download/nightly/rust-analyzer-linux or similar?

Igor Matuszewski (Apr 30 2020 at 16:18, on Zulip):

btw it feels nice to specify "rust-analyzer" as the LSP server path in the existing extension and most of the stuff just works out of box :)

Igor Matuszewski (Apr 30 2020 at 16:18, on Zulip):

(modulo applySourceChange and whatnot)

matklad (Apr 30 2020 at 16:18, on Zulip):

Yup (in VS Code, we do this(=download release directly) in bootstrapServer funciont)

matklad (Apr 30 2020 at 16:19, on Zulip):

Argh, applySourceChange is a big one tough

matklad (Apr 30 2020 at 16:19, on Zulip):

will hopefully taclke it next week

Igor Matuszewski (Apr 30 2020 at 16:19, on Zulip):

btw why codeaction/textedit from LSP wasn't enough?

matklad (Apr 30 2020 at 16:20, on Zulip):

We want to control the position of the cursor

matklad (Apr 30 2020 at 16:21, on Zulip):

Peek-2020-04-30-18-21.gif

matklad (Apr 30 2020 at 16:21, on Zulip):

The following won't be possible with stock code actions

matklad (Apr 30 2020 at 16:22, on Zulip):

as well as "ctrl+. on mod foo; creates&opens foo.rs file"

matklad (Apr 30 2020 at 16:23, on Zulip):

while we are at it @Igor Matuszewski what are your thoughts on mering TS extensions?

Igor Matuszewski (Apr 30 2020 at 16:23, on Zulip):

matklad said:

We want to control the position of the cursor

gotcha

matklad (Apr 30 2020 at 16:23, on Zulip):

I've looked, and they both clock at around 2k lines of code, which is not that bad

Igor Matuszewski (Apr 30 2020 at 16:23, on Zulip):

matklad said:

while we are at it Igor Matuszewski what are your thoughts on mering TS extensions?

I think that'd be ideal

Igor Matuszewski (Apr 30 2020 at 16:24, on Zulip):

I'd host something like a rust-lang/vscode-rust personally, though

Igor Matuszewski (Apr 30 2020 at 16:24, on Zulip):

to sort of make it more official/bless it

matklad (Apr 30 2020 at 16:24, on Zulip):

Which is the high-order bit here? A separate repo, or a rust-lang org?

Igor Matuszewski (Apr 30 2020 at 16:24, on Zulip):

not sure how that would impede the current dev workflow for rust-analyzer, I imagine that's something that has to be talked over separately

matklad (Apr 30 2020 at 16:24, on Zulip):

I sort-of find it usful to have the typescript and rust code in the same repository

Igor Matuszewski (Apr 30 2020 at 16:25, on Zulip):

well, both I imagine

Igor Matuszewski (Apr 30 2020 at 16:25, on Zulip):

Ideally we shouldn't really tie them in any way

matklad (Apr 30 2020 at 16:25, on Zulip):

Not sure....

matklad (Apr 30 2020 at 16:25, on Zulip):

Like, we do custom things, and when you hack on a custom thing, it's very conveient to me able to fix both sides at once

Igor Matuszewski (Apr 30 2020 at 16:26, on Zulip):

I personally feel like this sends a wrong message in the sense that it's only expected to work best for vscode

Igor Matuszewski (Apr 30 2020 at 16:26, on Zulip):

I too feel the burden when you need to juggle 3 vscode instances, output to a log file and debug the spawned extension, which the more streamlined approach helps with

matklad (Apr 30 2020 at 16:26, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/pull/3561 is a good example of feature which would be pretty awkward to do across several repos

Igor Matuszewski (Apr 30 2020 at 16:27, on Zulip):

but I'm not sure that's the right way - otherwise we'd have to lump all of the editors' code together with rust-analyzer

matklad (Apr 30 2020 at 16:28, on Zulip):

it's only expected to work best for vscode

It's quite literary true though: LSP impls in other editors tend to be sup bar

Igor Matuszewski (Apr 30 2020 at 16:28, on Zulip):

one thing that is annoying, though, is that you get a lot of bug reports for the vscode extension repository, which 99% should be meant for the LSP itself

Florian Diebold (Apr 30 2020 at 16:28, on Zulip):

as someone who uses RA from another editor (and sometimes updates the integration), I think it's still useful to have one 'reference' implementation

matklad (Apr 30 2020 at 16:29, on Zulip):

TBH, I'd be happy to have at least VS Code, Emacs and Vim plugins in the repo.

Igor Matuszewski (Apr 30 2020 at 16:29, on Zulip):

we'll have an official VSCode extension and the official IDE tool as Rust Analyzer, I think that should be easily discoverable for the reference implementation, personally

matklad (Apr 30 2020 at 16:29, on Zulip):

But at the moment Emacs-LSP preferes a monorepo wit all extensions, and vim has five different LSP plugins none of which is a clear favorite

Igor Matuszewski (Apr 30 2020 at 16:30, on Zulip):

at least neovim has it easy :stuck_out_tongue:

matklad (Apr 30 2020 at 16:30, on Zulip):

You mean the neovim-lsp which is in the unrelease 0.5 branch?

Igor Matuszewski (Apr 30 2020 at 16:31, on Zulip):

the one by autozimu, last time I've checked it's been the most popular one

Igor Matuszewski (Apr 30 2020 at 16:31, on Zulip):

but then again they added a support for LSP in trunk? or so I recall

matklad (Apr 30 2020 at 16:32, on Zulip):

debatable: https://www.reddit.com/r/rust/comments/g5ckqi/rfc_transition_to_rustanalyzer_as_our_official/fo90t1c/

matklad (Apr 30 2020 at 16:32, on Zulip):

I think coc.nvim is known for "works best", and the nvim-lsp (which I talked above) is going to be build in

Igor Matuszewski (Apr 30 2020 at 16:33, on Zulip):

gotcha

Igor Matuszewski (Apr 30 2020 at 16:33, on Zulip):

I was talking about https://github.com/autozimu/LanguageClient-neovim

Igor Matuszewski (Apr 30 2020 at 16:33, on Zulip):

should we move the discussion merging off this topic btw?

matklad (Apr 30 2020 at 16:34, on Zulip):

yup, right, there was a dedidated one

Last update: May 29 2020 at 17:30UTC