I have been using NixOS for 8 months, and I have only now realised there is a nix-community/nix-vscode-extensions flake that provides access to VSCode Marketplace / OpenVSX. Why are these not propagated back to nixpkgs? Is it because the automatic update of 40k + 3k packages would flood an already high-traffic repository?
If it were to be integrated into Nixpkgs, It’d happen in bulk updates like e.g. the haskell-updates work.
The collection seems to be about 4MiB compressed which is a lot but not that much. If most of these were things people actually use, that would be a trade-off that I could see being made.
I do question whether we need all 40k vscode plugins though. What’s the quality of the average vscode plugin like? If you took a random one, what would you think the chance would be that more than, say, 10 people would want to use it?
I don’t use vscode but 40k seems like quite a lot to me; to the point where I wouldn’t assume that most of them are useful to have.
To draw a comparison, emacs and vim each have on the order of 1000s of packages packaged in Nixpkgs. A typical emacs config will have on the order of 10s to 100s of packages, so 1-2 orders of magnitude less than the available packages. Do vscode users typically have 100s or 1000s of vscode extensions installed?
I think a better approach could be to use the updater infra of that project to produce a manually specified subset of the 40k packages where users would add the extensions they actually use. There is precedent for such procedure in the nextcloud plugins.
4 Likes
Not high, many are abandoned, many more are quasi-duplicates, still others are obsoleted by functionality in newer versions of the editor. Well I don’t know how that compares to other editors, but more often than not, per language/ecosystem, there’s 1-2 canonical extensions that work well and a bunch of skeletons of once-usable extensions.
The bigger concern I’ve seen is, of the few extensions we do have in nixpkgs, they’re often outdated to the point where they won’t even load in, and it’s somehow difficult to get bump PRs merged for that ecosystem. (Maybe 2 or 3 unique committers even review those.) I’ve also not really seen update scripts for those packages in most cases.
An extension for each language in use + utility stuff, sure. But nvim is more barebones vs vscode being more batteries-included, so not as many plugins needed with vscode in my exp. I don’t believe vscode has lazy-loading either, so thousands of extensions would be a perf issue, though there’s workarounds like only installing extensions in a given “workspace”/project. EDIT: I was wrong about lazy-loading, evidently: Activation Events | Visual Studio Code Extension API
Regardless, a few-dozen extensions would be more realistic.
Grain of salt, though, I don’t write that much code nowadays to keep up with the ecosystems, so I probably have less extensions than most.
2 Likes
In emacs, it’s a bunch of elisp packages for various functionality needed by some people. In such cases, there’s usually one or maybe two packages per purpose. For functionality that everyone needs (i.e. completion, LSPs), there’s usually like 3-4 different implementations of basically the same thing that each have loyal user bases.
Many packages are effectively abandoned but just keep working and/or don’t really require any changes because Emacs just doesn’t change very much.
Some packages’ functionality now exists within regular emacs but they are kept around for those who use a decade old emacs on Debian oldoldoldstable or something.
Well that’s bad.
If you want proper support for such major ecosystem package sets, you either need to auto-generate the packages or have a ton of maintainers.
I think the most manual ecosystem package set we have in Nixpkgs is python which has quite a few maintainers for individual packages and the ecosystem maintainers regularly run tool-assisted mass updates. All others that I know of auto-generate all packages and maybe do some manual fixups through overrides.
If you want to see vscode extensions in nixpkgs, I’d say porting the current subset to automatic package generation would be a very good first step.
3 Likes
Thanks for teaching me about how this stuff works.
Do vscode users typically have 100s or 1000s of vscode extensions installed?
I don’t think this is a relevant question to ask when considering the inclusion of 40k packages.
There are probably more VSCode extensions because the editor is more popular. It is not unlikely that the quality of the plugins is lower, and there are certainly often duplicate attempts of similar quality and lots of abandoned packages. I don’t know if the quality and deprecation of extensions is measured for other editors in nixpkgs?
I also don’t know of a good heuristic to determine if a package is worth including.
Here are some extension examples that are not obvious:
Searching open-vsx for “justfile”:
- nefrob/vscode-just-syntax (0.6k DLs, most recently updated 2 months ago)
- kokakiwi/vscode-just (2.0k DLs, most recently updated 4 years ago)
- skellock/just (2.3k DLs, archived on GitHub, most recently updated 7 years ago)
- wolfmah-vscode/just-syntax (0.2k DLs, most recently updated 10 months ago)
Which one(s) would you use / include? The analysis I did does not translate to 40k packages. You might argue 1. because it’s actively developed, 2. because it’s matured, and 3. because it actually works. In five years, the obvious choice is probably not the same.
I did a similar search for Typst plugins, and the answer there is also not obvious unless you ask around on Discord, dig in the issue tracker, and so on. The favored plugin is called Tinymist. One of the most popular LSP plugins has a debilitating formatting bug and no auto-preview.
of the few extensions we do have in nixpkgs, they’re often outdated to the point where they won’t even load in
I have not personally tried this yet.
But I can confirm that the list of extensions is very short.
If you want to see vscode extensions in nixpkgs, I’d say porting the current subset to automatic package generation would be a very good first step.
This seems like excellent advice, thank you.
Since nix-community/nix-vscode-extensions already contains automatic package generation, I suppose a natural step would be to see if I can adapt that package generation to nixpkgs. I wonder why this hasn’t happened yet. I’m unsure of the politics of actually including all packages, so I’m tempted to follow your advice and go for supporting all the existing packages first.