Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple directories #31

Closed
jacekszymanski opened this issue Jul 13, 2023 · 10 comments
Closed

Multiple directories #31

jacekszymanski opened this issue Jul 13, 2023 · 10 comments

Comments

@jacekszymanski
Copy link

The Netbeans extension (asf.apache-netbeans-java), possibly others, have multiple directories in the zipfile, and this causes the build to fail:

error: builder for '/nix/store/spmw2bry62skgchvpb6qkk8rf926r745-vscode-extension-asf-apache-netbeans-java-18.0.0.drv' failed with exit code 1;
       last 3 log lines:
       > unpacking sources
       > unpacking source archive /nix/store/rqpc0q8117cy5jcn8hhd84vk92006icd-apache-netbeans-java-18.0.0.zip
       > unpacker produced multiple directories
@jacekszymanski
Copy link
Author

Found a workaround:

(asf.apache-netbeans-java.overrideAttrs (_: { sourceRoot = "extension"; }))

@deemp
Copy link
Collaborator

deemp commented Jul 16, 2023

We fetch extensions as .zip archives that get unpacked when building an extension derivation. The sourceRoot attribute (see the nixpkgs manual) of an extension derivation affects the unpackPhase of the derivation.

@jacekszymanski
Copy link
Author

This much I figured out, indeed it was where I took this sourceRoot from. Now I think how it would be possible to - in a way similar to what is being done with Intellij plugins, see here - have some specialExts.nix file where extensions that need special treatment, like the Netbeans one, would receive it.

I'll look into it and hopefully come back with a pull request.

@deemp
Copy link
Collaborator

deemp commented Jul 18, 2023

@jacekszymanski
Copy link
Author

Great! So I think I can close this issue now 👍

@deemp
Copy link
Collaborator

deemp commented Jul 19, 2023

@jacekszymanski, please, check that it works. I have a quite slow Internet connection and can't nix build.

UPD: it finally worked!

@jacekszymanski
Copy link
Author

Yes, I can confirm it works.

@FraGag
Copy link

FraGag commented Feb 18, 2024

Extension ms-vscode.cmake-tools recently started to fail to build as well. Version 1.17.14 builds fine, but versions 1.17.15 and up fail.

# Version 1.17.14 (succeeds)
nix build github:nix-community/nix-vscode-extensions/856a8c1902513fa72f86963bd9f3c9238828c23a#extensions.x86_64-linux.vscode-marketplace.ms-vscode.cmake-tools

# Version 1.17.15 (fails)
nix build github:nix-community/nix-vscode-extensions/f495145caabb9a3b5bb3ae2815a66db1c3fbe31d#extensions.x86_64-linux.vscode-marketplace.ms-vscode.cmake-tools

Since 1.17.15, the .vsix contains additional _rels and package directories, which appear to contain a digital signature for the extension.

The workaround described in #31 (comment) works, but considering that .vsix files have a fixed structure, I thought, "Why not just set sourceRoot = "extension"; for all extensions?" So I went ahead and submitted NixOS/nixpkgs#289721 to nixpkgs, since nix-vscode-extensions is relying on vscode-utils from nixpkgs to define the derivations for VSCode extensions.

@deemp deemp mentioned this issue Feb 18, 2024
3 tasks
@jacekszymanski
Copy link
Author

I'm not sure whether the extension directory must be named extension, have you found it documented anywhere?

From what I remember the .vsix has a manifest file that points at a package.json which in most (all?) extensions happens to be in an extension directory, but I didn't find out then whether it is a documented subdirectory or a default build packaging which some extensions might not follow?

@FraGag
Copy link

FraGag commented Feb 18, 2024

Hmm, no, truthfully I just assumed. I used nixpkgs-review on my change and all VSCode extensions defined in nixpkgs built successfully, but there could be extensions that ended up empty, I suppose, I didn't check... If everybody is publishing extensions the same way though, then in practice every .vsix should have the extension in extension. In the worst case, we can just override the sourceRoot for the exceptions. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants