Fix No such file or directory on conda activate

[mokeyish]

Fix for issue #15818

[ghost]

All CLA requirements met.

[karrtikr]

Thanks for attempting a fix, although it still seems to be using source instead of conda. The most reliable known solution is to simply replace remove the firstActivate command, and only send conda activate <env>.

[mokeyish]

Thanks for attempting a fix, although it still seems to be using source instead of conda. The most reliable known solution is to simply replace remove the firstActivate command, and only send conda activate <env>.

Hi karrtikr, using source will be safer than using conda activate
when

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/.share/conda/bin/conda' 'shell.zsh' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/home/.share/conda/etc/profile.d/conda.sh" ]; then
        . "/home/.share/conda/etc/profile.d/conda.sh"
    else
        export PATH="/home/.share/conda/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

is not be sourced.

[karrtikr]

@mokeyish, I think the shell hooks in:

'/home/.share/conda/bin/conda' 'shell.zsh' 'hook' 

now takes care of the sourcing in the later conda versions. But maybe I'm not understanding it correctly.

Regardless, we're in the process of moving away from constructing our own activation commands to simply using what conda recommends. That way the responsibility of correct activation commands only lies with conda. If you think it's not being sourced and sourcing is necessary, please report that to conda so they can incorporate it as part of conda activate.

For the purposes of this issue #15818, please use conda activate instead.

[mokeyish]

@karrtikr using conda activate will cause error

conda may not be sourced correctly, So here try to find conda in known paths :

vscode-python/src/client/pythonEnvironments/common/environmentManagers/conda.ts

Line 322 in 03f4ec0

prefixes.push('/usr/share', '/usr/local/share', '/opt');

[karrtikr]

Thanks for clearing up the reason why source was used in the first place. However it's still a hack that we have to work around conda: #8770 (comment), and we are hesitant to rely completely on it. Let me know if this works out as well:

source ${activatePath}
conda activate ${condaEnv.toCommandArgumentForPythonExt()}

The intention is to send the conda activate command following it, so we do not totally rely on the source command.

[karrtikr]

Almost there, thanks for working on this.

[karrtikr]

This is no longer needed. Also, please turn getCondaFileFromInterpreter into a private method and remove it from the ICondaService interface.

[karrtikr]

This is still unaddressed.

[mokeyish]

getCondaInfo is used in condaActivationProvider.ts to check if conda sourced already.

[karrtikr]

I mean you can remove one of _getCondaInfo in favor of getCondaInfo.

Also, getCondaFileFromInterpreter comment is unaddressed.

[mokeyish]

Also, getCondaFileFromInterpreter comment is unaddressed.

getCondaFileFromInterpreter is used in another place.

[mokeyish]

You can still remove it from the ICondaService interface.

It's maybe helpful.

[karrtikr]

Actually the type of condaService is CondaService, not ICondaService, so it can be removed.

[karrtikr]

Ideally we should replacing those tests with tests for getActivationScriptFromInterpreter but I'm letting that go.

[mokeyish]

It's will cause error when I remove getCondaFileFromInterpreter directly.

[karrtikr]

I have checked your branch and removing it does not cause an error, but okay.

[karrtikr]

Also please add a news entry file thanking yourself (see news/README.md for instructions).

Ping me @karrtikr or re-request a review once all these comments are addressed.

[karrtikr]

Implemented suggestion: https://github.com/microsoft/vscode-python/pull/18989/files#r863217723

[karrtikr]

Lastly, please add some tests for the changes.

[karrtikr]

This is still unaddressed.

[karrtikr]

LGTM once #18989 (comment) is addressed and merge conflicts are resolved.

[karrtikr]

@mokeyish You might want to run git pull upstream main to resolve merge conflicts with main, after which this can be merged.

[karrtikr]

Thanks for working on this.

[mokeyish]

Looking forward to release new version for this as far as quickly.

[karrtikr]

Fix should be out in the pre-release version of the extension, you can use the following to try it out:

[Birch-san]

This still happened for me in v2022.8.0 and pre-release version v2023.9.10301005.

I installed conda 23.1.0 like this, on Ubuntu 22.10:
https://www.anaconda.com/products/distribution

bash Anaconda-latest-Linux-x86_64.sh
eval "$("$HOME/anaconda3/bin/conda" shell.bash hook)"
conda config --set auto_activate_base false
conda init

I think the problem is that vscode expects an executable to exist at "$HOME/anaconda3/condabin/activate", but there's nothing there. The true location is "$HOME/anaconda3/bin/activate".

Fixed by creating a symlink:

ln -s "$HOME/anaconda3/bin/activate" activate

You can get a better error message (i.e. it reveals which file it was trying to open) if you explicitly specify your conda executable path: