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.

[connor4312]

I'm not that familiar with how extension packs work / how they operate in search. For special cases before we've manually promoted certain extensions for certain searches, I think doing the same for Jupyter would be the reasonable approach here. @sandy081 / @chrisdias might have more info.

[rebornix]

For special cases before we've manually promoted certain extensions for certain searches

I think it's a good workaround to include Jupyter (maybe as the first one) for searching Kernel, Notebook Keymap or Renderer. cc @roblourens

[sandy081]

Extension packs are normal extension artifacts like others in the Marketplace, they are no different or special when it comes to search. It seems you need to define some common keyword for all these extensions so that they can appear in search together.

[isidorn]

Just talked to a Marketplace PM and the rough plan is that they look into search starting from Autumn. So before that I do not think it is reasonable to expect this.
@sandy081 proposal sounds like a decent workaround until we have more search capabilities from the Marketplace.
Or can you use a tag? Similar to how we have tag:debuggers

[connor4312]

Moving to "on deck" since this will happen whenever marketplace support arrives

[connor4312]

Talking with Kai we'd like to do this sooner than what the marketplace refactor time would allow, so I think we can actually make do with keywords/tags as Isi suggested. Unfortunately they accept but don't seem to index slashes as part of keywords, so we can't use the mimeType in here. But maybe we can just say that:

• for serializers and kernels, we search for the @tag:notebookSerializer<PascalCasedExtension>, and likewise for notebookKernels and their types.
• for renderers, we just look for @tag:notebookRenderer mimetype, so the mimetype runs as an ordinary text search

The only risk here is that this means the marketplace will eventually start getting a high cardinality of tags/keywords.

[connor4312]

@DonJayamanne once jupyter adopts this we can remove our special handling for the kernel installation recommendation 🙂 (1d6bfe0)

[isidorn]

@connor4312 this makes good sense.

The only risk here is that this means the marketplace will eventually start getting a high cardinality of tags/keywords.

I do not expect that there will be too many Notebook serializer extensions, and I do not think Marketplace should have a problem with a high number of tags. So we should be good here.