Stream: t-compiler/rust-analyzer

Topic: extension merging


Igor Matuszewski (Aug 24 2020 at 14:52, on Zulip):

I figured it might be a good idea to have an umbrella topic for the merger while it's under way.

@matklad I'm porting the update and release id/tag portions of the original code and would like to detach installed RA version from the extension version itself (and thus having to implement auto-update for 'stable' releases). The way I set up stuff before is so the user can specify releaseTag that will be downloaded. I propose that we can also specify stable (analogously to nightly) which will fetch the latest non-nightly release and which will be also gated behind some internal github poll timeout (e.g. 1hr like now, for nightly). Does that sound good?

Igor Matuszewski (Aug 24 2020 at 14:53, on Zulip):

So in addition to specifying e.g. nightly or 2020-08-24 we can also specify stable which should be auto-updating and try to pull the latest release from GH from time to time :smile:

matklad (Aug 24 2020 at 14:54, on Zulip):

Let me think for a moment, that's probably the most tricky bit...

FWIW, I think to just merge the extensions, it's fine to start with an explicitely specified path, and tackle auto-update in a separate PR

matklad (Aug 24 2020 at 14:54, on Zulip):

IE, I wouldn't find it unreasonable to say "hey, rust-lang/rust extension just uses the version from rustup"

Igor Matuszewski (Aug 24 2020 at 14:55, on Zulip):

the thing is, just merging as-is would lose the auto-update feature for RA as it is now

Igor Matuszewski (Aug 24 2020 at 14:55, on Zulip):

because we don't continuously release vsix extensions with bumped release versions from package.json that are later used to fetch 'latest' RA

Igor Matuszewski (Aug 24 2020 at 14:56, on Zulip):

and I'd prefer to tackle this now rather than have a period of time where we temporarily change the current release model for the extension

matklad (Aug 24 2020 at 14:57, on Zulip):

I mean, we should fix this before we say to folks "hey, switch to rust-lang/rust extension", but we don't have to do this in the initial PR

Igor Matuszewski (Aug 24 2020 at 14:57, on Zulip):

@matklad oh right I forgot about RA being shipped with rustup :face_palm:

Igor Matuszewski (Aug 24 2020 at 14:58, on Zulip):

let me think

Igor Matuszewski (Aug 24 2020 at 14:59, on Zulip):

where does it install the binary? to .cargo/bin/rust-analyzer?

matklad (Aug 24 2020 at 14:59, on Zulip):

it = rustup? I am not sure if the shim is already in place.

matklad (Aug 24 2020 at 15:00, on Zulip):

But we can ask rustup folks to do a minor release, and than yeah, it will be there

Igor Matuszewski (Aug 24 2020 at 15:02, on Zulip):

we can do that separately

Igor Matuszewski (Aug 24 2020 at 15:02, on Zulip):

okay then, let's leave the auto updates for later

Igor Matuszewski (Aug 24 2020 at 15:02, on Zulip):

Users can already set explicit releaseTag or path to the server binary

matklad (Aug 24 2020 at 15:07, on Zulip):

So, the original motivation behind tying the two versions together was to avoid doing HTTP requests without explicit user's consent.

That is, we were able to leverage marketplace's auto-update function. But just looking, locally, at the version of the extension and the version of the binary, we could say if we need to auto-update.

As opposed to querying GH API just to figure out if we need to update.

We definitely want separate release schedules for server and extension, at least for the time being. So, it seems like there's no other way than to implement auto-update on stable. And of course the question of defaults araises:

Igor Matuszewski (Aug 24 2020 at 15:15, on Zulip):

These are valid points, thanks for bringing up the original motivation. While I appreciate not doing the HTTP requests without user consent, I don't think needs as much attention:

However, if we also account for rustup as another means of auto-updating the server binary, then we might need to rethink on how to best tackle that and let the user select the release model they want to follow.

Let's leave this for now, then :) We can implement a simple auto-update after this PR; this should give us more time to rethink our possible options

bjorn3 (Aug 24 2020 at 15:55, on Zulip):

With rustup there should be no auto update. rust-analyzer is bound to a specific rust toolchain version. I don't think anybody wants an editor extension to suddenly update rustc while building a project.

Last update: Jul 28 2021 at 04:30UTC