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

Finalize or remove the notebookControllerKind API Proposal #168535

Closed
mjbvz opened this issue Dec 9, 2022 · 5 comments · Fixed by #175962
Closed

Finalize or remove the notebookControllerKind API Proposal #168535

mjbvz opened this issue Dec 9, 2022 · 5 comments · Fixed by #175962
Assignees
Labels
api api-finalization insiders-released Patch has been released in VS Code Insiders
Milestone

Comments

@mjbvz
Copy link
Collaborator

mjbvz commented Dec 9, 2022

From microsoft/vscode-jupyter#7373

Let's figure out what to do with the notebookControllerKind API proposal. Jupyter is currently the only consumer of it

@rebornix @DonJayamanne Can you please let me know:

  • If/how Jupyter is using this API today
  • If, in your opinion, this API should finalized or not? Are there any know issues / gaps with it
@mjbvz mjbvz added this to the January 2023 milestone Dec 9, 2022
@mjbvz mjbvz self-assigned this Dec 9, 2022
@rebornix
Copy link
Member

rebornix commented Dec 9, 2022

I'm leaning towards removing this API though we have seen interest in it. It was introduced to help us group controllers in the kernel picker, but now we are moving towards MRU. It would be a degraded experience if we remove it before having more users using the new MRU kernel picker.

With that said, I'm open to proposals to have it finalized if we find good use of it.

@gjsjohnmurray
Copy link
Contributor

Pinging @davidanthoff because of microsoft/vscode-jupyter#7373 (comment)

@mjbvz your comment that Jupyter is the only current consumer of it may be because it's still only proposed API. Not many extensions get the special privilege of being able to use proposed APIs and be published on Marketplace.

@davidanthoff
Copy link
Contributor

From Julia's point of view, I could see the new MRU experience replacing this. Agreed with @rebornix that the kind property shouldn't be removed until the MRU is finalized and default, otherwise the experience would really not be good.

With the Jupyter extension installed, things look like this to me:
image

A few comments on that:

  • It seems to use the description property to label sources. For example, the Julia extension provided controllers are grouped under Julia Language Support. Would it not make more sense to use the name of the extension there? Or provide the ability to provide a custom string? Julia Language Support there does not seem good to me, but I'm not sure how we could change that.
  • Could the Local Kernel Specs... be renamed to Local Jupyter Kernel Specs...? That would make it clear where that entry comes from, namely the Jupyter extension.
  • The Local Python Environments... entry seems just a marketing entry for the Python extension. From a Julia user's perspective it always feels strange to be pushed towards that in the UI if one has never indicated any interest in Python in the first place.

@rebornix
Copy link
Member

rebornix commented Dec 9, 2022

@davidanthoff thanks for your feedback, they make good sense and we have discussed some of the wording, like using "Jupyter Kernel Specs". We will address other feedback in issue #168647

@davidanthoff
Copy link
Contributor

Actually, here is another idea: if the notebookControllerKind property were to be finalized, then we could start to use it with the previous iteration of the UI in the same way that the Jupyter extension is using it right now.

In the new MRU UI, could the notebookControllerKind be the string by which the top level grouping happens? I.e. instead of using the description of the extension, or the name of the extension, could the notebookControllerKind be used if it is set?

That would enable a scenario where things move forward now before the MRU story is finalized, and then there would also be a use-case for the notebookControllerKind in the new MRU UI.

Also, I think this issue here is a dup of #168535, but given that more discussion has happened here, it probably makes sense to close #168535 and continue here.

@mjbvz mjbvz modified the milestones: January 2023, February 2023 Jan 19, 2023
@mjbvz mjbvz modified the milestones: February 2023, March 2023 Feb 7, 2023
mjbvz added a commit to mjbvz/vscode that referenced this issue Feb 8, 2023
For microsoft#168535

As discussed, we will stop showing the `kind` in the new MRU kernel quick pick
mjbvz added a commit that referenced this issue Feb 8, 2023
Don't use kind in kernel MRU quick pick

For #168535

As discussed, we will stop showing the `kind` in the new MRU kernel quick pick
c-claeys pushed a commit to c-claeys/vscode that referenced this issue Feb 16, 2023
Don't use kind in kernel MRU quick pick

For microsoft#168535

As discussed, we will stop showing the `kind` in the new MRU kernel quick pick
mjbvz added a commit to mjbvz/vscode that referenced this issue Mar 2, 2023
mjbvz added a commit to mjbvz/vscode that referenced this issue Mar 13, 2023
mjbvz added a commit that referenced this issue Mar 15, 2023
* Remove the flat kernel picker

For #168535

* Adding stubs for unit tests

* Remove unnecessary test for old kernel picker.

---------

Co-authored-by: rebornix <penn.lv@gmail.com>
mjbvz added a commit to mjbvz/vscode that referenced this issue Mar 15, 2023
@vscodenpa vscodenpa added unreleased Patch has not yet been released in VS Code Insiders insiders-released Patch has been released in VS Code Insiders and removed unreleased Patch has not yet been released in VS Code Insiders labels Mar 15, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Apr 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api api-finalization insiders-released Patch has been released in VS Code Insiders
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants