How to get the last version of the extension compatible with the specified vscode version?

[cathaysia]

I use nix to install vscode. Since flake.lock cannot be updated in such a timely manner, and the vscode version of nix is not always the latest. Expansion incompatibilities often arise. Is it possible to automatically fetch the last extension compatible with a specified vscode version?

UPD: nix4vscode solves this problem.

[deemp]

No, we don't provide such functionality.

Every revision (state of the repository at a commit) of nix-vscode-extensions contains a set of the latest versions and a set of the release versions of extensions.

Additionally, we provide the forVSCodeVersion function. You can use an older revision of nix-vscode-extensions and check that it provides extensions compatible with your version of VS Code.

UPD: you can find all extension versions via a script in haskell/requests.sh.

UPD1: @cathaysia makes nix4vscode that allows to fetch extensions listed in a config and compatible with a given version of VS Code

[cathaysia]

All right. Is it possible to provide similar functionality in future?

[deemp]

Yes, maybe via a CLI

[cathaysia]

The CLI sounds more like a middle-of-the-road solution. Is it possible to automatically select a suitable version for the specified vscode version? Is this part of the functionality missing because of a limitation caused by nix itself or is it just that there is no plan/motivation to do it at the moment?

[deemp]

Selecting a compatible version of an extension requires the following information that should be stored in this repo.

• All versions of that extension.
• engine (compatible VS Code version) of each extension version.

"all versions" will definitely bloat this repo and make fetching it slower.

[cathaysia]

Yes, fetching all versions will undoubtedly result in a very large repository. In this case, I will close this issue first, and please feel free to open it later if you have better ideas

[MinerSebas]

As a compromise, you could check what the version of vscode on the current (un-)stable channel, to use as a lower-bound for inclusion.

[AmeerTaweel]

Another idea regarding this: For each extension. Store the latest version compatible with a specific VSCode version.

Example: Assume an extension has the following versions:

• Version u. Compatible with VSCode version a.
• Version v. Compatible with VSCode version a.
• Version w. Compatible with VSCode version b.
• Version x. Compatible with VSCode version c.
• Version y. Compatible with VSCode version c.
• Version z. Compatible with VSCode version c.

For such an extension, we only keep versions v, w, and z.

I think this combined with the idea of @MinerSebas can be a viable solution. Defining a reasonable lower-bound limits the number of versions. And we (at most, probably will be much less) store one version per extension per VSCode version from that lower-bound.

[cathaysia]

I want to think about it from another angle.

Is it possible to calculate the minimum required version of vscode in the current commit. Then tag this commit by vscode's version. If tag is existed, just update it to the lastest commit.

This will cause many extensions to be unable to use the latest version, but avoids breaking changes. The only concern is whether this function will be completely ineffective due to outdated extensions.

[AmeerTaweel]

@cathaysia Correct me if I'm wrong. But (I assume that) some older extensions will not be compatible with newer versions of VSCode. In that case, even if you have a version of VSCode more recent than the "minimum required", you might get incompatible extensions.

[cathaysia]

Yes, but if we specify the upper and lower bounds of the vscode version at the same time, the chances of conflict between the two boundaries will be high. So we can only assume that the low version extension is compatible with the high version vscode. In other words, the upgrade of vscode will not break compatibility.

What we need may not be a tag that works perfectly, but a tag that works in most cases. This stems from a compromise on warehouse size.

In fact, it might be better to be able to query the extended compatible version at "runtime". But it will introduce impure

[deemp]

I'm in favor of @AmeerTaweel 's idea (#41 (comment)).

Currently, we fetch latest and release extensions separately. API responses for latest extensions are small. API responses for release versions are large as they contain all extension versions.

If we're to get compatible versions for all extensions:

Cons:

• GH Action run time may increase for many responses will be large.
• Repo size will grow.

Pros:

• Maybe repo size won't grow dramatically as some extensions like rust-analyzer update VS Code version infrequently.
• The release and the latest extension versions will be in the same response. No need to manually list in a config extensions that need release versions.

Requests for the latest and release extensions are available in haskell/requests.sh (permalink).

P.S. closed the issue incidentally when typing on my phone.

[AmeerTaweel]

By the way, do you think this will be approved? Because if that is the case, we can keep only the extension versions compatible with whatever version of VSCode is in nixpkgs. That way we only have one version per extension, and we always have compatible versions. However, this depends on being able to merge with nixpkgs.

[arjan-s]

Sorry for this "me too" like answer, but I'm running into this issue too. Currently vscode is at version 1.81.1, while the latest pre-release ms-python.python requires 1.82.0 or higher. This cannot be solved currently, because:

• vscode 1.82.0 is not yet available in nixpkgs
• ms-python.python is not available in the extensions.x86_64-linux.vscode-marketplace-release set
• ms-python.python is not available in the (extensions.x86_64-linux.forVSCodeVersion "1.81.1").vscode-marketplace set

Can you think of a way to get this to work?

[deemp]

Sorry for silence. Started a new semester.

@AmeerTaweel

we can keep only the extension versions compatible with whatever version of VSCode is in nixpkgs

This option still implies that we process large responses. To see large responses, run haskell/requests.sh

[deemp]

@arjan-s

Can you think of a way to get this to work?

If the latest release version of ms-python.python is compatible with vscode 1.81.1, you can add ms-python.python to the config (README). Then, the release version of ms-python.python will be fetched.

[yangm97]

@deemp but only a set of very specific extensions are available on the -release closure =/

[AmeerTaweel]

@yangm97 I think that @deemp meant that you fork the repo and add the extension you want until we figure something out.

[AmeerTaweel]

To see large responses, run haskell/requests.sh

@deemp I will run it and see...

[AmeerTaweel]

@deemp maybe a better work to describe the response was "huge" lol.

The GitHub action takes around 20 minutes to finish. The proposed idea will make it 20 hours. We should find a way to tell the API to send shorter responses.

[AmeerTaweel]

I found an open issue about this.

[cathaysia]

I'm currently working on a node2nix-like software. It reads the vscode version and extension list from toml and then generates nix expressions. If all goes well, it should be open in the next week or so. If this tool is written, nix-extensions may no longer be needed to make changes.

[deemp]

@cathaysia, cool idea!

[cathaysia]

I've just removed the hardcoded data from the code and implemented a very basic prototype (so haven't even added a README yet), but it should be enough to illustrate some of my thinking. I left a config.toml in the repository, just run cargo run -- -f config.toml to see the generated nix expressions printed to the console.

https://github.com/cathaysia/nix4vscode

[yangm97]

@deemp maybe a better work to describe the response was "huge" lol.

The GitHub action takes around 20 minutes to finish. The proposed idea will make it 20 hours. We should find a way to tell the API to send shorter responses.

Sorry if I'm being captain obvious but does the API provide any sort of caching header? Like. etag or last-modified? Wouldn't it be possible to cache these and make use of HEAD requests before attempting a full GET?

[deemp]

IDK. How would you use it? We need to get all extensions to get an extension version per a VS Code version.

[yangm97]

So the idea would be to store the cache header for each request somewhere (ideally the CI cache but could be on the repo if it makes implementation easier, those headers are short anyway). The first run would probably take a long time but as extensions don't get frequently updated all at once, subsequent runs would be much faster as the HEAD requests could be parallelized without straining the API.

[cathaysia]

I just updated the nix4vscode's README. Anyone interested?

talk about nix4vscode here is not a good idea, so I just don't mention it then.

[deemp]

I added a link to nix4vscode to your first message in this issue. Anyone interested can continue discussing it in your repo.

[cathaysia]

thanks😃

…

________________________________ From: Danila Danko ***@***.***> Sent: Saturday, September 9, 2023 1:02:56 PM To: nix-community/nix-vscode-extensions ***@***.***> Cc: DragonBillow ***@***.***>; Mention ***@***.***> Subject: Re: [nix-community/nix-vscode-extensions] How to get the last version of the extension compatible with the specified vscode version? (Issue #41) I added a link to nix4vscode to your first message in this issue. Anyone interested can continue discussing it in your repo. — Reply to this email directly, view it on GitHub<#41 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6ALA2ACDRUIF2DH7PJLXZP2ABANCNFSM6AAAAAA3N72434>. You are receiving this because you were mentioned.Message ID: ***@***.***>