deprecate nix-vscode-extensions in favor of nix4vscode

[deemp]

This issue is a result of the discussion of #41.

nix-vscode-extensions

Provides the latest versions of almost all extensions and release versions of chosen extensions from VS Code Marketplace and Open VSX.

Advantages

• flake provides extension patches for all users (link)
• doesn't require configuration files
• supports VS Code Marketplace and Open VSX
• flake is updated automatically via a GH Action
• provides platform-specific extensions
• extension info is in JSON format and can be reused without nix

Disadvantages

• flake is large due to files with extensions config
• doesn't provide extension versions compatible with the user's VS Code
• not very maintainable due to a) Haskell and b) non-professional code
• possibly can't be scaled to support release versions for all VS Code versions (link)
• latest versions include pre-release versions that expire soon

nix4vscode

nix4vscode provides the latest versions compatible with a given VS Code version (see #41) for chosen extensions.

Advantages

• provides extension versions compatible with the user's VS Code
• generates expressions only for necessary extensions
• written in Rust and seems to be maintainable
• can be possibly scaled to all extensions and used in nixpkgs (link)

Disadvantages

• doesn't provide extension patches for all users
• requires a configuration file
• a user has to generate expressions
• doesn't provide platform-specific extensions (extensionFromVscodeMarketplace doesn't use platform)
• extension info is in Nix and cannot be easily reused without nix
• doesn't support Open VSX
• is currently unstable

Summary

Despite some disadvantages, the approach of nix4vscode seems to be more promising than that of nix-vscode-extensions. In my opinion, most of nix4vscode disadvantages can be overcome. Then, it will be a truly personalized tool for getting VS Code extensions.

Suggestions

@deemp, @AmeerTaweel:

• Don't implement the solution (link)
• Decide if need to deprecate nix-vscode-extensions and at what stage of readiness of nix4vscode
• If decide to eventually deprecate:
  • Edit README
    • Warn in the README of nix-vscode-extensions about deprecation and link this issue
    • Put into README a link to the nix4vscode repo
  • Edit wiki (link):
    • Link to nix4vscode instead of nix-vscode-extensions

@cathaysia

• Transfer nix4vscode to nix-community to get more contributors
  • Perhaps @spikespaz will be interested to work on nix4vscode as it's written in Rust
• Consider listed disadvantages and turn some of them into issues in the nix4vscode repo

[spikespaz]

Thanks for ping.

[cathaysia]

Thanks, I will forward nix4vscode to nix-community and list the issue you mentioned in the issue. Thank you very much for your trust in nix4vscode. As of now, my configuration uses both nix-vscode-extensions and nix4vscode, if you plan to deprecate nix-vscode-extensions, I would try to completely transfer the configuration to nix4vscode for further testing.

[deemp]

nix-vscode-extensions will stay here at least until nix4vscode is mostly feature-complete and stable.

[AmeerTaweel]

• nix4vscode is added to nix-community.
• The last commit was two weeks ago.

@cathaysia is nix4vscode mostly feature-complete and stable?

[cathaysia]

No, there's still a lot of work to be done, but a simple scenario (generating nix expressions from a configuration file) should be enough, and the likelihood of changes is unlikely. If everything goes well, I will complete these tasks before the Spring Festival this year.

…

________________________________ From: Ameer Taweel ***@***.***> Sent: Sunday, October 22, 2023 9:35:30 AM To: nix-community/nix-vscode-extensions ***@***.***> Cc: DragonBillow ***@***.***>; Mention ***@***.***> Subject: Re: [nix-community/nix-vscode-extensions] deprecate nix-vscode-extensions in favor of nix4vscode (Issue #47) * nix4vscode is added to nix-community. * The last commit was two weeks ago. @cathaysia<https://github.com/cathaysia> is nix4vscode mostly feature-complete and stable? ― Reply to this email directly, view it on GitHub<#47 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6AJF4WIWQTZUIGOLDZLYARZ6FAVCNFSM6AAAAAA4YD5DBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTHE3DKMJZGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[spikespaz]

@cathaysia

I have not had the time in months to look at the project, but I want to see a way to use it entirely from Nix without IFD. Not sure how that would look, but I don't really want to have to run a separate command to update everything. I want to write expressions that choose versions based on Nix config.

Until that happens, nix4vscode cannot replace this repo for me.

[spikespaz]

Additionally, I elected myself for that job. I was thinking of generating a shell script (from the rust binary) that sets up environment and links, which can be used in the activation scripts or shell nix.

[cathaysia]

Work is in progress to provide something like nix-vscode-extensions. But you know, I need to work and rest, and I also need time to fall in love, so I don’t have much time left for open source work. The functions required by nix4vscode are not complicated, and one to two weeks should be enough to write and test, but this requires a whole block of time, rather than always squeezing out some scattered time. In addition, if you have good ideas to propose in nix4vscode, PRs are always welcome.

[spikespaz]

I wasn't trying to rush you. I too have not been able to work on it, because I do not live exclusively in a code editor (contrary to what some may believe).

[cathaysia]

thank you for understanding. :)