Comments (30)
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.
from nix-vscode-extensions.
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
from nix-vscode-extensions.
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 versiona
. - Version
v
. Compatible with VSCode versiona
. - Version
w
. Compatible with VSCode versionb
. - Version
x
. Compatible with VSCode versionc
. - Version
y
. Compatible with VSCode versionc
. - Version
z
. Compatible with VSCode versionc
.
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.
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
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
from nix-vscode-extensions.
All right. Is it possible to provide similar functionality in future?
from nix-vscode-extensions.
Yes, maybe via a CLI
from nix-vscode-extensions.
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?
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
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
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
@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.
from nix-vscode-extensions.
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
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
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
.
from nix-vscode-extensions.
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 theextensions.x86_64-linux.vscode-marketplace-release
setms-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?
from nix-vscode-extensions.
Sorry for silence. Started a new semester.
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
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
@deemp but only a set of very specific extensions are available on the -release
closure =/
from nix-vscode-extensions.
@yangm97 I think that @deemp meant that you fork the repo and add the extension you want until we figure something out.
from nix-vscode-extensions.
To see large responses, run haskell/requests.sh
@deemp I will run it and see...
from nix-vscode-extensions.
@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.
from nix-vscode-extensions.
I found an open issue about this.
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
@cathaysia, cool idea!
from nix-vscode-extensions.
@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?
from nix-vscode-extensions.
IDK. How would you use it? We need to get all extensions to get an extension version per a VS Code version.
from nix-vscode-extensions.
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.
from nix-vscode-extensions.
I added a link to nix4vscode to your first message in this issue. Anyone interested can continue discussing it in your repo.
from nix-vscode-extensions.
from nix-vscode-extensions.
Related Issues (20)
- Github copilot missing HOT 1
- Improve documentation? HOT 5
- Is it possible to use this with `home-manager` without using flakes? HOT 7
- Multiple directories HOT 10
- How to use forVSCodeVersion with flake? HOT 4
- Build problems and solutions
- build codelldb from github HOT 2
- template appears to be missing HOT 1
- Attempting to use ziglang extension fails HOT 2
- Tweak User Settings HOT 2
- @parcel/watcher prebuild not found in nrwl.angular-console HOT 4
- How to create custom extension from .vsix url? HOT 1
- I'm not sure how to use this with homemanager? HOT 2
- Consider inverting "release" and "latest" HOT 3
- Some extensions b*tch about not being able to write into the extensions directory HOT 3
- deprecate nix-vscode-extensions in favor of nix4vscode HOT 10
- vscode version compatablity fix HOT 2
- Is it Possible to use with Home-Manager? HOT 4
- What is `__filter` in flake.nix? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nix-vscode-extensions.