Activate conda environments using the path instead of the conda env name

[NowanIlfideme]

A project-local conda environment will be seen by VS Code, but it will fail to activate automatically. I would guess this is because it looks at the end of the path for the environment name and always activates by name, rather than by path. However, for environments created with the -p pathname flag, this will fail (as you can't even set environments name for them with -n).

Environment data

• VS Code version: 1.30.1
• Extension version (available under the Extensions sidebar): 2018.12.1
• OS and version: Windows 10 V 1803
• Python version: 3.7.0, conda 4.5.12
• Type of virtual environment used: conda

Steps to reproduce:

1. Create empty directory (mine was D:/TST) for project and add a random .py file (for ext to load), open in VS Code.
2. Run conda create -p ./localenv python=3.7 in that directory.
3. Select this environment as the Python interpreter.
4. Make sure "python.terminal.activateEnvironment": true (or unset) in settings.
5. Open new terminal (EDIT: as in interactive terminal, e.g. a REPL; for me, this was the cmd, but running code in the REPL has the same effect: it fails to activate the env, and thus runs in the default environment).

Expected behaviour

Automatic environment activation by path, rather than name:

D:\TST>activate ./localenv

(D:\TST\localenv) D:\TST>

OR

D:\TST>activate "D:\TST\localenv"

(D:\TST\localenv) D:\TST>

Actual behaviour

When opening a terminal:

D:\TST>activate localenv
Could not find conda environment: localenv
You can list all discoverable environments with `conda info --envs`.
D:\TST>

[NowanIlfideme]

Note that all conda environments made with the -p argument will fail this way.

Also, the environment docs show this working with the virtualenv, but it has conda directly next to it (second image). I understand if this is just in the "not yet implemented" territory (I've read that you've been seeking to talk more closely with the Anaconda team), just slightly misleading as it currently is shown.

[ericsnowcurrently]

Hi @NowanIlfideme. Thanks for letting us know about this. I wasn't able to duplicate the issue just by opening a (Python) terminal. However, I did see the problem when opening a REPL. We'll investigate further.

[faroit]

This issue is does also trigger a problem when using the "install linter" command

[gonzalocasas]

I am seeing the same issue with local conda environments created with prefix (e.g. -p ./env). Discovery works but then activation fails every time I open a new terminal (cmd in my case).

[sindzicat]

The same problem.

[lpravda]

I was pointed here from my stack-overflow question, so I assume this is a similar problem: https://stackoverflow.com/questions/54922399/activate-conda-environment-stopped-working-in-vscode

[mirkancal]

I have the same problem

[DonJayamanne]

Changing to enhancement, as this is by design, currently we only support envs with a name see here https://code.visualstudio.com/docs/python/environments#_conda-environments

[lpravda]

Changing to enhancement, as this is by design, currently we only support envs with a name see here https://code.visualstudio.com/docs/python/environments#_conda-environments

Sorry for the confusion, but I do have an environment name in the problem I experience. So are they not related?

[muammerugur]

conda create -n myenv python=3.7
// myenv klasörünü oluşturur.
activate myenv
// envirementi aktif eder
conda install tensorflow

[alorcamo]

I have the same problem

[lpravda]

I think I have found the solution eventually in some other thread here. However, don't really know which one, so I can't give a proper credit to the person who came up with this. However, putting:

    "terminal.integrated.env.osx": {
        "PATH": ""
    }

into settings.json file did the trick, until the bug is fixed.

[NowanIlfideme]

@lpravda Tried on Windows. This has a lot of side-effects (can't reach any system exec files, for example), unless I'm missing something obvious.

[lpravda]

@lpravda Tried on Windows. This has a lot of side-effects (can't reach any system exec files, for example), unless I'm missing something obvious.

I have a mac, so I assume that terminal.integrated.env.osx option works on mac only. There are other options terminal.integrated.env.linux and terminal.integrated.env.windows for different OS. But dont have a windows, so cant really test it.

[NowanIlfideme]

I obviously used the Windows version. 😛
The output I get for setting the PATH to null, when starting a terminal through the normal Conda, is this:

D:\.......>D:/Conda/Scripts/activate
'chcp' is not recognized as an internal or external command,
operable program or batch file.

(base) D:\.........>conda activate myenv
'chcp' is not recognized as an internal or external command,
operable program or batch file.

(myenv) D:\..............>

This is with a named env, not a local env (which is what this issue was for). I haven't tested whether it works with a local env, but the negative effects of having a broken PATH would be definitely worse than having it work. Can you point to the thread where you got this?

Anyways, this is marked as an enhancement now, so hopefully there's a less-hackish way to do it in the future. For now I've just made a global environment per (group of) project(s).

[cpoptic]

I confirm this issue occurs on Windows 10 in VS Code version 1.36.1

conda env list shows all my Conda environments, but
conda activate gym (or whatever env_name) does absolutely nothing. The virtual environment does not activate in the VS Code terminal.

Now when I run the exact same command conda activate gym from a command prompt, it successfully activates the environment with no problem. So I'd posit that there's strong evidence that the issue is related to a VS Code bug.

[ruilvo]

I have a similar problem.
To create a local venv in the project directory, let's call it gym for the sake of the example, I use the command:

conda create --prefix ./gym

Problem is that vscode tries to activate it with activate gym instead of activate ./gym yielding an error of not found.
Running conda env list returns something like this:

base                 <base env path>
                     <project_path>/gym

The venv created from path doesn't have a name, so activating without the ./ prefix yields an error.

[EBjerrum]

I have this issue too. Can't use various features when I have conda environments created with -p. In my case it's necessary to use prefixes in conda environments due to integration with our compute cluster. Looking forward to seeing a solution.

[lkindrat-xmos]

I found a hacky workaround on linux, if you created environments with -p. First find where your activate script is (I'm gonna assume that it's under ~/miniconda3/bin/). Then do

cd ~/miniconda3/bin/
mkdir vscode && cd vscode
cp ../activate .
sed -i 's/conda activate "$@"/[[ -d "$@" ]] \&\& conda activate "$@\/" || conda activate "$@"/g' activate

Finally add "python.condaPath": "~/miniconda3/bin/vscode/activate" to your settings.json. You can do this in your workspace or on the user level.

Not sure how to do this on Windows, but the idea is to check if the argument to conda activate is a directory, and if it is, append the separator so that conda treats it as a path rather than a name of an environment.

You might run into troubles if there is an environment with the same name as the path you specified to conda create --prefix.

[karthiknadig]

Proposed Fix:

Need to update parseCondaEnvironmentNames, if we don't find a name we should leave it empty.
src\client\interpreter\locators\services\condaHelper.ts

Anywhere we use envInfo.name should be updated to use path if the name is empty string:
src\client\common\terminal\environmentActivationProviders\condaActivationProvider.ts see getActivationCommandsForInterpreter

Ensure that the path has a trailing path separator.

[DonJayamanne]

@karthiknadig
conda run can be used with path names as well. Validated.

[kimadeline]

✅ Validated using 2019.12.48501-dev