Do not select nor display messages when venv created through command by another extension

[DonJayamanne]

Today we use the python command to create a new python environment from the Jupyter Kernel picker
At the end of the creation the python extension displays a mesage indidating this has been selected as the active interpreter

Would it be possible to hide this message and not select the env as the active interpreter when this command is called from another extension (optionally provide a flag or new command to make this possible)

[brettcannon]

Possibly/probably, but we need to discuss among ourselves whether we want to continue to push folks into running the command directly or some other API.

We can also make the message more useful, i.e. what we installed from, such as a requirements.txt file.

[DonJayamanne]

can also make the message more useful, i.e. what we installed from, such as a requirements.txt file.

@brettcannon from jupyters perspective i don't think we'd want the requirements.txt file to be read and installed. The expectation is a new env (blank) is created. optionally we could prompt the user to install stuff from requirement files

[luabud]

it's still another optimization we could make to the flow, in terms of allowing users to choose whether to install the requirements or not. @cwebster-99 did some user studies and one of the patterns we saw is that folks wanted the ability to "customize" what was the command was going to do (#20264 ). I wonder if there's something we could somewhat similar to the dev containers extension, where each box would be a step in the flow?

[brettcannon]

from jupyters perspective i don't think we'd want the requirements.txt file to be read and installed.

Why not? Are you seeing users with fully independent notebooks from the rest of the workspace the majority of the time? Personally, when I use notebooks I always have a requirements file to list Jupyter and any dependencies I have in order to make the notebook run.

I wonder if there's something we could somewhat similar to the dev containers extension, where each box would be a step in the flow?

I've been planning this from the start for the command (even polled folks on Twitter about it to find out if we needed multi-select or quick pick), but I apparently forgot to open an issue. 😅 Just created #20277 to track this.

[DonJayamanne]

Why not? Are you seeing users with fully independe

i take it back, i don't have any data to backup such a proposal. and it makes sense to do what you're suggesting

[DonJayamanne]

@brettcannon @luabud
Just wanted to clarify, the message displayed today indicates the .venv that was created via the Kernle picker in a notebook ends up getting selected as the active interpeter.
I.e.

• Open a notebook
• Go into kernel picker
• Create a new venv or conda env
• At the end of taht process, Python extension displays a message indicatin that env was selected
• If you create yet another env (e.g if venv was used earlier, and now you use conda for the same folder), once again Python displays the message

I don't think Python should change the interpretr at this stage, and optionally not display such a mesage.

I believe this message in this workflow is not necessary

[luabud]

I can understand not changing the selected interpreter when the environment is created as part of the kernel picker workflow. But given we do select it, I think the message is important to indicate to users that the env creation process has been finished, otherwise they don't know (especially if they don't have a Python file on focus, because then the selected environment won't be displayed in the status bar).

Is the problem here the message itself, or that we auto select it?

[DonJayamanne]

But given we do select it, I think the message is important to indicate to users that the env creation process has been finished, otherwise they don't know (especially if they don't have a Python file on focus, because then the selected environment won't be displayed in the status bar).

But doesn't the end of the progress message indicate it has completed
Displaying a message on top of closing the progress message seems like an unnecessary step to indicate the completion.

[luabud]

I personally don't find the progress notification disappearing enough because you don't know if it went away automatically or if it was complete. At least on our user studies most users appreciated it as a signal of completion.

[brettcannon]

Is there still an ask here since we explained why we think the notification is useful to users?

[DonJayamanne]

Sorry, will close this issue.
Makes sense