any particular reason to close them? I've been busy with real-life events

any particular reason to close them? I've been busy with real-life events

I think, that we should create something like whitelist of extensions (just market place id + probably license) which can build without any special packaging and also have kind of script which generates nix expressions from that list. Using the script we can update build expressions (or add) in generated.nix from that list. Inspiration: update_installed_exts.

I am not sure what functions script should provide, here are some proposal:

• update all extensions in that list (will generate generated.nix with expressions of extensions at latest version)

In general, there are some questions about strategies how to pack extensions from Marketplace and the functionality of the script:

• maybe in Marketplace are some categories which can be placed in that list naturally, so some automatic checking and extending the list would be nice
• alternative is not to have whitelist of simple extensions, but generate expression for all extensions from Marketplace and if extension require special packaging, it will be blacklisted and pack manually or unsupported
• if we run update script, then it can eventually update multiple expressions in once, so there will be only one commit per extension or one commit at all
• the list and the generated set should be alphabetically sorted
• policy of updating extensions and verification

The workflow will look like:

1. want to update all extension in the list
   • run update script, (verify?), and commit (commit per extension or for all?, i would prefer for all, naturally)
2. i can't see extension in the list and also in default.nix
   • do 1.
   • add extension id and its license to the list
   • run update, which add expression to the generated.nix
   • test it:
     • if works than just commit (msg 'init at VERSION')
     • else try to manually pack it and add to default.nix
3. extension in the list stop working:
   • do 1., if it now works you are done
   • remove from the list and regenerated
   • find the working version (commit)
   • copy build expression from that commit to default.nix, make commit (downgrade), you are done
   • alternatively try to manually pack and add extension at the latest version and add it to default.nix

The idea of all of previous paragraph is to bring a bigger set of Marketplace extensions to this repo. So, user just type which extensions he wants and it works. If he want to use specific version, than he can fallback to manually building extension as descibed in wiki. For me, there are still some open questions how to handle this and which strategy should be preferred.

To sum up:

• default.nix will contain extensions which need some manual intervention to pack it
• default.nix also contains extensions from generated.nix (via callPackage and // operator)
• generated.nix contains extensions from the list generated by the script
• if you want to add extension which is simple, you add it to the list, run update script to generate expression for that extension
• running the script we can update multiple extensions in once (which are mentioned in the list)

See: my extensions handling, especially: update script, list, merging generated in default.nix

You may want to look at how vimplugins are handled, it's very similar. I would be open to changing the current paradigm as it is quite painful to quickly iterate on the vscode extensions