Conda activation is failing

[MarekOzana]

Environment data

• VS Code version: 1.3.1
• Extension version (available under the Extensions sidebar): 2019.1.0
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): Miniconda 3.6.6 64-bit ('py36': conda)
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
• Relevant/affected Python packages and their versions:

Expected behaviour

VSC opens interactive python using active py36 environment

Actual behaviour

1. VSC is open with active ('py36': conda) environment
2. Python: Show Python Interactive window
3. Error message:
   Jupyter kernel cannot be started from 'Python 3.6.6 64-bit ('py36': conda)'. Using closest match Python 3.6.6 64-bit ('mro': conda) instead.

Steps to reproduce:

1. Open VSC in empty directory
2. Python: Select Interpreter
3. select 'py36'
4. Python: Show Python Interactive window

Logs

Relevant Part from Developer Tools > Console Log:

Python Extension: Python Extension (Error in getActivatedEnvironmentVariables, method:getActivatedEnvironmentVariables): 
Error: Command failed: 
C:/Users/marek.ozana.XCF/AppData/Local/Continuum/miniconda3/envs/py36/Scripts/activate && conda activate py36 && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python C:/Users/marek.ozana.XCF/.vscode/extensions/ms-python.python-2019.1.0/pythonFiles/printEnvVariables.py
Could not find conda environment: py36
You can list all discoverable environments with `conda info --envs`.
	at ChildProcess.exithandler (child_process.js:303:12)
	at ChildProcess.emit (events.js:182:13)
	at maybeClose (internal/child_process.js:961:16)
	at Process.ChildProcess._handle.onexit (internal/child_process.js:248:5)
t.log @ console.ts:134

The problem seems to be that process is already in 'py36' environment and thus fails when trying to activate py36 again:
C:/Users/marek.ozana.XCF/AppData/Local/Continuum/miniconda3/envs/py36/Scripts/activate && conda activate py36

[MarekOzana]

I re-installed the Don's extension "Jupyter 1.1.4" and it nicely opens Jupyter notebook in the correct environment. So the issue is only with the new interactive python.
Jupyter Notebook log:

Starting Jupyter Notebook
jupyter notebook --no-browser --port=8888 --NotebookApp.allow_origin="*"
[I 10:24:22.506 NotebookApp] [nb_conda_kernels] enabled, 3 kernels found
[I 10:24:23.050 NotebookApp] The port 8888 is already in use, trying another port.
[I 10:24:23.051 NotebookApp] The port 8889 is already in use, trying another port.
[I 10:24:23.158 NotebookApp] [jupyter_nbextensions_configurator] enabled 0.4.1
[I 10:24:23.245 NotebookApp] JupyterLab extension loaded from C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py36\lib\site-packages\jupyterlab
[I 10:24:23.245 NotebookApp] JupyterLab application directory is C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py36\share\jupyter\lab
[I 10:24:23.257 NotebookApp] [nb_conda] enabled
[I 10:24:23.258 NotebookApp] Serving notebooks from local directory: d:\Projects\Python\Misc\BUG
[I 10:24:23.258 NotebookApp] The Jupyter Notebook is running at:
[I 10:24:23.258 NotebookApp] http://localhost:8890/?token=148d5e58990e52b07a6557afcc389e81a240e95a14d83f22
[I 10:24:23.258 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 10:24:23.271 NotebookApp] 
    
    To access the notebook, open this file in a browser:
        file:///C:/Users/marek.ozana.XCF/AppData/Roaming/jupyter/runtime/nbserver-22232-open.html
    Or copy and paste one of these URLs:
        http://localhost:8890/?token=148d5e58990e52b07a6557afcc389e81a240e95a14d83f22
[I 10:24:25.815 NotebookApp] Kernel started: 08fa9738-4a01-4d45-9f57-6bf66ce9ba70
[I 10:24:27.038 NotebookApp] Adapting to protocol v5.1 for kernel 08fa9738-4a01-4d45-9f57-6bf66ce9ba70

[MarekOzana]

I noticed that Python: Create Terminal has the same issue with incorrect environment:

Microsoft Windows [Version 10.0.17763.316]
(c) 2018 Microsoft Corporation. All rights reserved.
D:\Projects\Python\EcoCharts\MarketUpdate>C:/Users/marek.ozana.XCF/AppData/Local/Continuum/miniconda3/envs/py36/Scripts/activate

(base) D:\Projects\Python\EcoCharts\MarketUpdate>conda activate py36
Could not find conda environment: py36
You can list all discoverable environments with `conda info --envs`.

It tries to activate 'py36' environment while already being in it. When listing environments I get:

(base) D:\Projects\Python\EcoCharts\MarketUpdate>conda info --envs
# conda environments:
#
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\keras
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\mro
base                  *  C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py36
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py37

So in summary VSC is in 'py36' environment but incorrectly calles it 'base'.
However in this case the issue is not fatal since 'py36' is activated so one can continue working. In case of jupyter one cannot start 'py36'....

[ronglums]

Not data science specific. also happened in the terminal window.

[MarekOzana]

I am not sure if you experience the same issue. I get this issue only on Windows.
In summary:

1. create conda environment py36
2. select py36 in VSCode
3. creation of python terminal (or interactive python) fails because py36 environment cannot be activated inside of py36 environment.

On Windows I get this error (mind that it incorrectly uses ../envs/py36/../activate and not base activate):

.../Continuum/miniconda3/envs/py36/Scripts/activate
(base) C:\Test>conda activate py36
Could not find conda environment: py36
You can list all discoverable environments with `conda info --envs`

On Linux the activation correctly uses the base conda envirnment and works nicely:

source /home/.../miniconda3/bin/activate
conda activate py36

I tried on several different Windows computers using clean miniconda install and I am getting allways teh same issue. It stops me from using interactive python on Windows. The only workaround right now is to use the deprecated Don's jupyter extension, but unfortunately this does not work with python 3.7.
Thank you for your time and help fixing this bug.

[DonJayamanne]

@MarekOzana

• Please could you provide a screenshot of the bottom left statusbar of VS Code
• Please could you provide the output of the console window (Help->Toggle Developer Tools).
  • That will contain an output of the environments (versions of interpreter, conda environment names, etc) that'll help diagnose the issue.
• Please could provide the output for the following command in the terminal conda --version
• Please could provide the output for the following command in the terminal conda list --json

[MarekOzana]

I opened VSCOde, selected py36 interpreter and run command: Python: Show Interactive Window
See attached

• screenshot (including the status bar)
  
• log file with Developer Tools console
  DevTools-Console-1550653184196.log
• list.json file with output from conda list --json in py36 environment
  list.json.txt
• conda version is conda 4.6.2

conda --version
conda 4.6.2

• and for full picture here is list of all conda environments:

(base) C:\>conda info --envs
# conda environments:
#
base                  *  C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3
keras                    C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\keras
mro                      C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\mro
py36                     C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py36
py37                     C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\py37

The problem seems to be that the extension tries to activate py36 environment while already being in the py36 environment, and thus cannot find it.

Thank you for your time Don.

[MarekOzana]

Don, does my comment above give you all the info you need?

[DonJayamanne]

@MarekOzana

1. VSC is open with active ('py36': conda) environment

How did you manage to do this?
Did you activate py36 in the terminal and then launch VSC from within that terminal?

[MarekOzana]

@DonJayamanne

• I always open VSCode by right-clicking in file explorer and selecting "Open with Code" context menu.
• If the interpreter is not selected (the first time I open a directory) I use crtl-shift-P: "Python: Select interpreter"

I never start VSCode from a terminal with an already activated conda environment. conda and python are not even on path. Correct way of activating environment is:

c:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\Scripts\activate
(base) C:\>conda activate py36
(py36) C:\>

While it seems that VScode-python extension is activating inside of environment and then tries to activate it again:

C:/Users/marek.ozana.XCF/AppData/Local/Continuum/miniconda3/envs/py36/Scripts/activate
(base) C:\>conda activate py36
Could not find conda environment: py36
You can list all discoverable environments with `conda info --envs`.

[DonJayamanne]

Expected approach for activation:

c:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\Scripts\activate
(base) C:\>conda activate py36
(py36) C:\>

What we're doing is as follows:

• We're activating the environment using the shell scripts in the environment specific folder. This results in activation of environment and then we attempt to activate it again using conda scripts.
• Looking at the previous approach, we activate the base environment, then activate the other environment.

C:/Users/marek.ozana.XCF/AppData/Local/Continuum/miniconda3/envs/py36/Scripts/activate
(base) C:\>conda activate py36
Could not find conda environment: py36
You can list all discoverable environments with `conda info --envs`.

[MarekOzana]

Any progress on this one? I had a workaround which worked until the latest python extension update:

1. Activate base conda environment in terminal,
2. start code from this terminal
3. open Interactive window.
   Unfortunately even this stopped working after the last python extension update. Pity, such a great editor, if just jupyter interactive window worked....

[MarekOzana]

I found out that the issue happens only if conda-build package is installed in the environment.
I created two clean environments.

• One without conda-build: conda create -n ok_env python jupyter
• And one with conda-build package: conda create -n bug_env python jupyter conda-build

Then I tried to start python interactive window in VSCode in each of the environment. It succeeded in the first environment (without conda-build package: ok_env):

and it failed in the second environment (with conda-build package installed: bug_env):

So in summary, there is something with conda-build package being installed in the environment which is messing up VSCode activation.

[DonJayamanne]

Are you able to activate the conda environment from the terminal (manually).
I.e. does conda activate bug_env work in the terminal?

[MarekOzana]

Hi Don,Yes activation of the environment form console works fine.

(base) C:\>conda activate bug_env
(bug_env) C:\>

Comment whether or not this issue is another bug

I think this issue is the same as reported above:

1. VSCode is first calling activate inside of bug_env environment
   C:/Users/mare.../envs/bug_env/Scripts/activate
2. and then tries to activate the environment again
   conda activate bug_env
   

See the full log file in the attachment:
VSCode-bug_env_log.log

Also if one tries to start python terminal from bug_env one gets familiar error:

D:\>C:/Users/mare.../envs/bug_env/Scripts/activate
(base) D:\>conda activate bug_env
Could not find conda environment: bug_env
You can list all discoverable environments with `conda info --envs`.

and when listing conda environments in this terminal window one gets:

(base) D:\>conda info --envs
# conda environments:
#
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3
base                  *  C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\bug_env
                         C:\Users\marek.ozana.XCF\AppData\Local\Continuum\miniconda3\envs\live

so bug_env is activated and fails to activate itself again.

All of the above works fine in ok_env which differs just by not having conda-build:

[xhochy]

I ran into the same problem and tracked down the source of the issue to https://github.com/Microsoft/vscode-python/blob/8cd0996e4fbb50f5aa4ca2d05b320a370ae121a6/src/client/interpreter/locators/services/condaService.ts#L254-L262

Here we try to activate the environment using the conda installation that is installed in the environment. I cannot think of a situation where this would work. One must activate the conda that created the environment hence this cannot be the conda installed in that environment as we would otherwise have a chicken-egg situation.

@rchiodo Maybe you can add more context why these two blocks exist as you wrote the environment activation code initially in #3506 ?

[rchiodo]

Sorry I must be missing something. That line of code is just looking in the Scripts folder for the conda executable next to the python that was found. Why is this causing a problem?

The way this stuff was supposed to work was we call conda activate for the base and then inside the base, call the conda activate 'env-name'. It looks like we don't find the base. I'm guessing we're using the python.exe path and assuming it's for the 'base' and that there isn't one for the sub environment.

For example, here's what happens on my own machine:

Python Extension: Activating Environment to capture Environment variables, C:/Users/rchiodo/AppData/Local/Continuum/anaconda3/Scripts/activate && conda activate jupyter && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python f:/vscode-python-1/pythonFiles/printEnvVariables.py

C:/Users/rchiodo/AppData/Local/Continuum/anaconda3/Scripts/activate is where the base conda was installed. It's next to where the python.exe is found.

The 'jupyter' environment is the secondary environment it's activating.

It looks like for @MarekOzana, the first activate is the wrong one. We must be using the python installed in the environment instead.

[xhochy]

@rchiodo The problem is only occuring when you have conda installed in the non-base environment.

The following steps show the issue:

• Install conda
• Create an env test-issue
• Load VSCode, chose test-issue as the interpreter and open a terminal:

root@e1176206961b:/home# source /opt/conda/bin/activate
(base) root@e1176206961b:/home# conda activate test-issue
(test-issue) root@e1176206961b:/home# 

• Install conda in the test-env
• Open a new Terminal in VSCode:

root@e1176206961b:/home# source /opt/conda/envs/test-issue/bin/activate
(base) root@e1176206961b:/home# conda activate test-issue
Could not find conda environment: test-issue
You can list all discoverable environments with `conda info --envs`.

(base) root@e1176206961b:/home# 

Removing the code lines I mentioned earlier resolves the problem.

[rchiodo]

Ah that's because it doesn't find an activate so falls back to the default location.

Is it normal to install conda in a test environment? Is that so you can have a different conda?

[xhochy]

It is not normal but still happening from time to time. You can use conda programmatically to inspect your environment and also use this to build packages.

In the case of conda environments, I would never call the activate scripts but only ever call the default location. activate should only be called in virtualenv situations. The above linked code is though only executed when we're already sure that we're dealing with a conda environment.

[mingwandroid]

Is it normal to install conda in a test environment? Is that so you can have a different conda?

Now-a-days, conda is only ever installed in the base env. We don't even put hooks to it into other envs anymore. Instead, the base env's condabin directory remains on PATH always.

[xhochy]

Is it normal to install conda in a test environment? Is that so you can have a different conda?

Now-a-days, conda is only ever installed in the base env. We don't even put hooks to it into other envs anymore. Instead, the base env's condabin directory remains on PATH always.

Maybe to add my usecase why I have conda installed in a conda environment itself: I have code that uses conda itself to get information about an environment and also creates a set of environments out of this environment.

[mingwandroid]

Maybe to add my usecase why I have conda installed in a conda environment itself

How have you done this? Conda prevents it!

[MarekOzana]

The bug happens when I install conda-build package (used to build and develop packages locally) inside an environment.
The steps are describe in my post above:
#4402 (comment)

conda create -n bug_env python jupyter conda-build

[xhochy]

Maybe to add my usecase why I have conda installed in a conda environment itself

How have you done this? Conda prevents it!

Just like with any other package:

% conda create -p $(pwd)/test python=3.7 conda
Collecting package metadata: done
Solving environment: done

## Package Plan ##

  environment location: /Users/uwe/test

  added / updated specs:
    - conda
    - python=3.7
…
% conda activate /Users/uwe/test
% ls test/lib/python3.7/site-packages/conda
__init__.py     __pycache__     activate.py     base            common          core            exports.py      history.py      instructions.py misc.py         plan.py         shell
__main__.py     _vendor         api.py          cli             compat.py       exceptions.py   gateways        install.py      lock.py         models          resolve.py      utils.py
% ls test/bin/conda
test/bin/conda
% ls test/bin/activate
test/bin/activate

Also it should not prevent it as I want to use the Python API of the package: https://docs.conda.io/projects/conda/en/latest/api/