Allow user to set their own custom activation commands for the interpreter

[karrtikr]

Upon creating a terminal, an activation command to activate the current environment is sent to the terminal.

There are often issues like #8770, where environment is not activated due to extension sending the wrong activation commands.

Example: An activation command used to work with conda x.x.x, but conda y.y.y changed something so it is no longer valid. And if the extension does not keep up with the change, activating the environment would fail.

Allow user to set their own activation commands for the interpreter they're using. Often they know the correct activation commands as you can notice in #8770.

[DonJayamanne]

@karrtikr @karthiknadig Please see comments in #8770 (comment)

I agree with you about omething so it is no longer valid. And if the extension does not keep up with the change,
And also I believe in an alternative solution, which is to fix/deprecate the hack instead of allowing users to customize the commands. Fix it for everyone. E.g. on my machine i too don't need the double activation.

I believe only seasoned users would go into VS Code settings to customize the activation commands. Other would probably give up and just activate manually or file issues or even worse..

[karrtikr]

And also I believe in an alternative solution, which is to fix/deprecate the hack instead of allowing users to customize the commands

Yes we should definitely fix it. We should do our best in sending the correct default commands. But having support for custom activation command also seems like a nice workaround to have for the user.

There're things we can do for discoverability. For eg. we can test if an activation failed for a user and notify them of this option.

[1st]

+1 I also need to set some env variables (db name, db user and password) when opening a new terminal tab. I do it now by source ~/.zshrc where I have such variables set. But will be better to set these variables per-project, because each project needs its own DB and credentials, and I don’t want to store them in a file like settings.py for known reason.

Waiting for this feature. Hope that this will help me to set env variables in the terminal, as well as do other shell commands (like change directory to src when open a new terminal window).

[otisdog8]

+1 This would allow me to fix an issue that I've been having #13854, and would allow me to quickly and easily fix similar issues without building from source or waiting for a release. It also gives users more control over their setup.

[GuillaumeDesforges]

+1 Same for me with #14794, it would even allow to use Nix shell

[raratiru]

Is #12020 going to help?

[Khazbs]

Came here from #9917. There are a lot of things VSCode doesn't do right, and activating a Python virtual environment by source-ing the activate script instead of using workon is definitely one of them. The postactivate script is just ignored. Bummer! I really hope this feature would allow us to workon our virtual environments.

[gerardlt]

As a workaround for the virtualenvwrapper use case, the following rather hideous hack could be added to your premkvirtualenv hook:

envname="${1}"
envpath="${WORKON_HOME}/${envname}"

echo "Patching activate script for ${envname} to always call virtualenvwrapper"

cat /dev/fd/3 "${envpath}/bin/activate" /dev/fd/4 3<< EOP 4<<EOS > "${envpath}/bin/patched_activate"
# This file has been modified by virtualenvwrapper premkvirtualenv script

if [ "\${BASH_SOURCE-}" = "\$0" ]; then
    echo "You must source this script: \\$ source \$0" >&2
    exit 33
fi

# Presence of cd_after_activate var is used as a proxy to indicate running from workon function
if [[ ! -v cd_after_activate ]]; then
    echo "activate sourced directly - calling virtualenvwrapper"
    workon ${envname}
else
EOP
fi
EOS

mv "${envpath}/bin/activate" "${envpath}/bin/unpatched_activate"
mv "${envpath}/bin/patched_activate" "${envpath}/bin/activate"

Any virtual envs created with that will always call workon if the activate script is sourced directly (not via workon).
With a little thought, the same script can be used to modify existing virtual envs.

It's not nice, might not be posix compliant, and I can't speak for the security of it, but it does make the relevant hooks get run.

Would be much nicer to get proper custom activation commands though! :-)

[cwebster-99]

Closing as we do not plan to implement this change in the Python extension.