Notebook serializer and renderers recommendation

[rebornix]

With the stabilization of notebook serializer and output renderers, we may also need better extension recommendations (and search support) for notebook extensions.

• Category/tag for notebook extensions
  • ✔️ category notebooks
  • tags: serializer/kernel/renderers
• Serializer suggestions
  • search by file extension (extension recommendations for file extensions work partially but not accurate)
• Kernel/controller suggestions for notebook documents
  • search by notebook view type / file extension
  • search by cell language
• Renderer suggestions
  • search by output mime type and renderer dependencies Support searching the marketplace for compatible renderers #121222 (upstream Support searching the marketplace for compatible notebook renderers  vsmarketplace#60)

[connor4312]

@rebornix I think this was very briefly mentioned in my 1:1 with Kai. What work does this issue entail, I think most of these are marketplace asks. Should we put together a doc for them or otherwise push on that team?

Also, adding to August to reflect the iteration plan

[connor4312]

From discussion today:

• Serializers: we already can find these when opening a file type via the @ext query, which derives from the activation events
• Kernels: we want a Notebook > Kernels subcategory. Extensions in this category who have an activation event onNotebook:<type> (where type is the notebook type declared by a serializer) will be considered kernels for that given type and appear in recommendations
• Renderers: we want a Notebook > Renderers. Requirements for renderer searching is captured in the previously-created Support searching the marketplace for compatible notebook renderers  vsmarketplace#60

For keybindings, which were brought up as a question, we discussed making their contribution point similar grammars where they point to a separate json file. This allows them to declare a scope, and VS Code can use a single notebook keybinding set at a time. It also makes authoring keybindings a little easier.

[rebornix]

@connor4312 while playing around with triggering auto-search in the extension viewlet (search for renderers/keymaps), it occurred to me that we may want to consider showing extension pack even when searching for renderers/keymaps/kernels. The very first time when users open an ipynb file, there would be multiple places triggering the search (run a cell will trigger kernel search, a rich output will trigger renderer search) and most of the time (at least at the beginning) what users really need is the Jupyter extension pack. If we only show individual extension, users would have to install multiple extensions on getting started.