Notify users to upgrade conda when applicable

[DonJayamanne]

Conda activation failing for a number of users in Jupyter extension

Over the past few months I've been seing a lot of bugs filed by users with logs containing the following

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run

    $ conda init <SHELL_NAME>

Currently supported shells are:
  - bash
  - fish
  - tcsh
  - xonsh
  - zsh
  - powershell

See 'conda init --help' for more information and options.

These are either users on SSH, WSL, and even local
I understand that getting conda working for everyone isn't easy.
& Jupyter extension has code to work around some of the issues in Python extension as well.

I'd like to

• Get rid of the hacks in the Jupyter extesnion and always rely on Python extension to activate any enviornment
• Try to get some of the hacks/fall backs into the Python extension
• Come up with a plan on what we do when users are unable to get some conda enviornments working
  • Do we inform users that Conda versions <= n are not supported
  • Do we inform users that Conda in WSL, SSH, etc are not supported until and unless...
  • Etc

Note: Today we don't have as many failures as we should because we have custom code in Jupyter extension that serves as a fall back when Python exesnion fails to activate the Conda enviornment.
https://github.com/DonJayamanne/vscode-jupyter/blob/main/src/platform/common/process/environmentActivationService.node.ts#L306

This is something I have already shared with @karrtikr @karthiknadig some time ago in a few meetings.

This will ensure more users will continue to have success with Conda envionments.
Else we'd have to continue to implement work arounds in Jupyter extension to keep resolving these activation issues, and reverting these changes would only result in breaking existing user.

Some related issues

• Kernel not starting, conda environment errors on remote SSH #19965
• conda environment fails to load properly on remote machine #11324
• Failure to activate Conda Environments created using the --prefix argument (on Unix) #18044
• Issues with new conda env on WSL vscode-jupyter#11813

I believe the soliution identified here #19965 (comment) would solve a large number of these issues (including WSL, SSH and the like). I.e. fall back to old actiavtion when conda run fails. However @karrtikr might have a better solution and more ideas on what could be improved.

[brettcannon]

What's the activation for? Just for a terminal, or for running commands? If it's the former then Kartik has started to look into this and has an initial plan to try out. If it's the latter than we are moving to conda run under the guidance of the conda team who have asked people to file bugs with them when something doesn't work.

[DonJayamanne]

If it's the latter than we are moving to

Its the latter

[brettcannon]

Then the conda has asked us to have users (or us personally when we are so motivated) to file bugs at https://github.com/conda/conda/issues and work towards adopting conda run. https://github.com/conda/conda/releases/tag/22.9.0 has the last critical bug fixed for us to completely switch over (debugging is our last execution context that isn't using conda run). We are now waiting for conda to tell us what their support timelines are for conda versions before we switch debugging over completely and tell users we only support conda 22.9 and newer only.

Do you know what version of conda people who are having problems are running? We found a lot of users having issues were using versions like conda 4.8 which is nearly 3 years old. Once we asked them to upgrade (which no one actually balked at), the situation improved.

[DonJayamanne]

Do you know what version of conda people who are having problems are running? We found a lot of users having issues were using versions lik

No i don't

[DonJayamanne]

Once we asked them to upgrade (which no one actually balked at), the situation improved.

I'm hoping for a solution as follows, i.e. unblock users without having to wait for for users to file a bug at our end to be notified of a solution
E.g

• Jupyter extnesion calls into Python extension to activate a Conda env
• Python extension determins the conda version etc, and realizes the fact that conda needs an update
• Some how Jupyter extension/Python extension will then notify/prompt the user to update Conda

This way users are able to unblock themselves without having to reach out to us.

[brettcannon]

• Jupyter extnesion calls into Python extension to activate a Conda env

We're working on a potentially new way to activate terminals. Until that's done there's no plan for an API (although if we do end up using the environment context API for terminals then everyone gets the activation for "free").

• Python extension determins the conda version etc, and realizes the fact that conda needs an update

We are still waiting for conda to tell us what their support timelines are going to be. Once we have that we could potentially notify users that they are outside of support. But I'm not sure if we want to do that as it's not a guarantee things won't work, just that we don't make a guarantee things will work. This is why we don't tell e.g. Python 3.6 users they are unsupported even though debugpy doesn't work; if you just use the run button then everything works out fine.