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

vscode-extensions.bbenoist.vscode-doxygen: init at 1.0.0 #86380

Closed
wants to merge 1 commit into from

Conversation

@firmero
Copy link
Contributor

firmero commented Apr 30, 2020

Motivation for this change

Doxygen language support for Visual Studio Code.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
Doxygen language support for Visual Studio Code.
@firmero firmero force-pushed the firmero:vscode-bbenoist.Doxygen branch from af6c2af to 85f0efe May 1, 2020
@firmero firmero closed this May 1, 2020
@jonringer
Copy link
Contributor

jonringer commented May 2, 2020

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

@firmero
Copy link
Contributor Author

firmero commented May 2, 2020

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

@jonringer
Copy link
Contributor

jonringer commented May 3, 2020

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

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

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.