vscode-extensions: allow dependencies on other VSCode extensions

GsakuL commented 3 months ago

Describe the bug

VS Code Extensions can have dependencies, due to sharing code; or because they are an "extension pack", which bundles other extensions.

In most cases, when I install an extension with "real" dependencies (not just n extension pack), I "don't care" what it needs; but I want it to "just work". Essentially like all other "normal" (non vs code) packages

Steps To Reproduce

install pkgs.vscode-extensions.ms-vscode.cpptools-extension-pack into VS Code via HomeManager:

{
programs.vscode = {
  enable = true;
  mutableExtensionsDir = false;
  extensions = [ pkgs.vscode-extensions.ms-vscode.cpptools-extension-pack ];
}
}

rebuild
start VS Code (may reload windows due to extension change)
look at Extension-Tab @installed c++
see that e.g. "C/C++ Themes" (cpptools-themes) is missing (I have cpptools and cmake-tools installed manually)

Expected behavior

the following pkgs.vscode-extensions extensions should be installed alongside (automatically):

ms-vscode.cpptools
ms-vscode.cmake-tools
ms-vscode.cpptools-themes

Screenshots

Additional context

I could not find information if a proposal like this was already rejected. This is also not a "breaking bug", I just didn't think the other issue categories fit any better It's more of a improvement/feature request.

Currently I have to list every dependency manually, and if one gets added in the future I need to check and adjust again. Also if ones get removed as deps, they would accumulate since I wouldn't notice.

VSCode behaved strangely when having a "mixed" extensions directory, thus I made it non-mutable.

Also I wanted to (amongst others) add/contribute marus25.cortex-debug however, it has 4 dependencies. It be nice to also have it "documented in code", that these depend on each other and should also be updated together (also if one extension is used by many other different extensions, that have different people as maintainers)

Dependencies may be read from the package.json under extensionDependencies if there could be a build-check. (but would have to be opt-in, as to no break current extensions)

also there is a difference between "dependencies" and "extension pack" also shown in the marketplace. (extensionPack in the package.json) however I feel like in both case, the referenced extensions there are intended to be also installed

Notify maintainers

@superherointj since they created the document on how to add new extensions @eadwu @synthetica @bobby285271 @Enzime since they are noted as maintainers for vscode

Metadata

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.36, NixOS, 24.11 (Vicuna), 24.11.20240703.9f4128e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.4`
 - nixpkgs: `/nix/store/dk2rpyb6ndvfbf19bkb2plcz5y3k8i5v-source`

Add a :+1: reaction to issues you find important.

superherointj commented 3 months ago

Extension packages can already include any other Nix dependencies.

So what you want is to have an option for automatically adding 'other extensions'? This might make sense.

Home-Manager is another repository/project. So, here we are thinking in nixpkgs terms. Basically what an extension package ought to be.

Implementation-wise we need to understand how this 'multiple extensions' is going work. Each extension right now is a discrete package. How do you plan implementing this?

D3vil0p3r commented 2 months ago

vscode-extensions.ms-vscode.cpptools seems failing to build.... could you check please?

GsakuL commented 2 months ago

@superherointj (please excuse my knowledge of syntax and terminology, I'm a beginner with nix)

yes, I'd like to add a (or multiple) pkgs.vscode-extension as a dependency of another pkgs.vscode-extension. You'd only add direct deps, but in the end, you could re-create the tree

a bit of reference: https://github.com/GsakuL/mynix/blob/main/modules/home/programs/vscode/default.nix

I know my case it's HM, but my idea should work similar.y My (very primitive) idea would be:

list the required extensions in the extension definition
maybe have a "magic" expression
- not sure how "breaking-change"-friendly that would be, so maybe like pkgs.vscode-extensions-with-dependencies
- or a config flag?
this expression then creates lists, which include the main extension itself and its direct dependencies
this expression would probably have to be recursive(?) so all sub-dependencies could be resolved
in the end, flatten the list (like i do in my config)
- not sure if this could be type-annotated tho

Or maybe something like pkgs.vscode-extensions.<author>.<extension>.with-dependencies which returns like [ self ] ++ self.depencencies (i hope you understand what i mean by that, even if the syntax is wrong). If there are no dependencies, than it should not error. (because of the " self + ..." meaning(?) But this would require one to update more of their configuration more that "just a flag", or just a let-definition (like in my case).

Not sure if it would be "nice in general" if this "dependencies-feature" should be Optional, whichever implementation. Since, when someone updates one extension, all connected ones may be in the need of an update themself. Which is the case now also, but now it might be "silently failing" depending on the collection of extensions installed by a user (no build errors, but runtime errors in vscode)

Do you understand what I intended with my description? Otherwise maybe i could work out some "minimal working example"/proof-of-concept, but I'd probably need more time at this.

eadwu commented 2 months ago

I'll drop my thoughts here.

Forgo this plan. Unless someone dedicates themselves to mirroring updates from vscode, coverage will likely be limited and you experience breakages / outdated versions.

Personally, I have transitioned to a DevContainer based workflow and dumped the majority of my extensions to be installed per-project, my overlay updates on a weekly cadence using the bash script in the repository. I have not had any problems with linker issues or any of the classic issues specific to NixOS since.

If you truly have some extension that will not work without being in nixpkgs, that should really be the only the case it should be added in my opinion.

NixOS / nixpkgs