Deactivate environment command broken for venv

[AnAngryPlatapus]

Workaround

This is a known issue, see #22037 (comment) for a workaround in bash.

Expected vs. Actual

Expected: running deactivate exits the venv in that particular shell context

Actual: running deactivate shows command isn't found
(data-loader-prototype-py3.10) [admin-smiller@UUE2OLY01L olympus]$ deactivate
bash: deactivate: command not found

Behaviour

I would expect the environment to be properly sourced in my bash shell context. Instead commands like "deactivate" are not found given the inital shell context.

Steps to reproduce:

1. Select a python interpreter via the python plugin
2. Open an new terminal
3. Try deactivating the default environment

[karrtikr]

deactivate not working is actually a limitation of new approach, where we do not run ./.venv/bin/activate script in terminal to activate the env. Activate script contains the following block which registers the deactivate shell hook. If you wish to not activate or deactivate the env you can either:

• Turn off auto-activation: "python.terminal.activateEnvironment": false, and reload the window & reopen the shells.
• Or add the deactivate shell hook to the very end of ~/.bashrc file and restart the shell. Make sure to also initialize the variables that deactivate shell hook relies on: #22037 (comment).

[karrtikr]

Apologies, we would also need to initialize the variables that deactivate shell hook relies on. Try adding:

_OLD_VIRTUAL_PS1="${PS1:-}"
_OLD_VIRTUAL_PATH="$PATH"
if [ -n "${PYTHONHOME:-}" ] ; then
    _OLD_VIRTUAL_PYTHONHOME="${PYTHONHOME:-}"
fi

before the the deactivate shell hook in ~/.bashrc.

I can personally confirm it works.

[jwtanx]

Yes it works, adding this combined block of code into ~/.bashrc Thanks.

_OLD_VIRTUAL_PS1="${PS1:-}"
_OLD_VIRTUAL_PATH="$PATH"
if [ -n "${PYTHONHOME:-}" ] ; then
    _OLD_VIRTUAL_PYTHONHOME="${PYTHONHOME:-}"
fi

deactivate () {
    # reset old environment variables
    if [ -n "${_OLD_VIRTUAL_PATH:-}" ] ; then
        PATH="${_OLD_VIRTUAL_PATH:-}"
        export PATH
        unset _OLD_VIRTUAL_PATH
    fi
    if [ -n "${_OLD_VIRTUAL_PYTHONHOME:-}" ] ; then
        PYTHONHOME="${_OLD_VIRTUAL_PYTHONHOME:-}"
        export PYTHONHOME
        unset _OLD_VIRTUAL_PYTHONHOME
    fi

    # This should detect bash and zsh, which have a hash command that must
    # be called to get it to forget past commands.  Without forgetting
    # past commands the $PATH changes we made may not be respected
    if [ -n "${BASH:-}" -o -n "${ZSH_VERSION:-}" ] ; then
        hash -r 2> /dev/null
    fi

    if [ -n "${_OLD_VIRTUAL_PS1:-}" ] ; then
        PS1="${_OLD_VIRTUAL_PS1:-}"
        export PS1
        unset _OLD_VIRTUAL_PS1
    fi

    unset VIRTUAL_ENV
    unset VIRTUAL_ENV_PROMPT
    if [ ! "${1:-}" = "nondestructive" ] ; then
    # Self destruct!
        unset -f deactivate
    fi
}

[karrtikr]

Thanks, I've edited the original comments so that folks can easily focus on the workaround. Created microsoft/vscode-docs#6590 so we officially document this limitation on VS Code docs.

[karrtikr]

Would it work if were to provide a command to create a new deactivated terminal? We're trying to understand why "deactivate" command is used, and if there are any alternatives we could provide.

cc/ @nikhilweee

I would like to deactivate the self-activated venv sometimes to switch to another venv

@jwtanx You mentioned that you needed to deactivate the existing venv to activate another venv. However when you activate another venv, that also deactivates any currently set venv, so "deactivate" command is not needed in this case.

[nikhilweee]

Yes, the option to not activate the default environment or to deactivate an auto-activated environment in certain cases would definitely be helpful. Personally, I use a separate tab in the integrated terminal to run commands which require a separate environment. For example, consider the case where I want to quickly check the state of a different environment:

# cd into different repository
$ cd different/repo
# activate env
$ source .venv/bin/activate
# check installed packages
$ pip freeze

[karrtikr]

I see. To my earlier point, you need not run the "deactivate" command to activate another venv. Activating another venv should already take care of deactivating any previous environment.

[nikhilweee]

That's interesting, I remember seeing two prompts when I activated another env but let me check this once again.

[karrtikr]

Ah, let me double check as well.

[karrtikr]

You're right, one would still need to add:

_OLD_VIRTUAL_PS1="${PS1:-}"
_OLD_VIRTUAL_PATH="$PATH"

at end of ~/.bashrc to make that work. Does that sound like a workaround you can adopt?

[nikhilweee]

Possibly, what about the case where I don't want another environment and just want to deactivate the auto activated env? It would be much nicer to have a solution which works out of the box without having to modify ~/.bashrc.

[karrtikr]

FWIW this solution should also work in that case, while I agree it's not as nice.

One solution could also be this:

source ./venv/bin/activate
deactivate

Activating selected venv again followed by a deactivate command should work as well. However that is currently blocked on microsoft/vscode#145234.

Let me know your thoughts about this.

[karrtikr]

FYI we have a new way which supports deactivate command out of the box without having to modify shell initialization files: #22448.

It's out in pre-release if you want to try it out, fix is only available on Windows for now: