Repository navigation
Allow user to set their own custom activation commands for the interpreter #8870
Description
Activity
Kartik Raj (@karrtikr) Karthik Nadig (@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..
Reacted by MarinAnd 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.
+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 ~/.zshrcwhere 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 likesettings.pyfor 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
srcwhen open a new terminal window).+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.
+1 Same for me with #14794, it would even allow to use Nix shell
Reacted by Tobias Bergkvist, Raymond Gauthier and Lucas SavvaIs #12020 going to help?
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 usingworkonis definitely one of them. The postactivate script is just ignored. Bummer! I really hope this feature would allow us toworkonour virtual environments.Reacted by gerardlt, Jamie Grasing and nyLiaoAs 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
workonif 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! :-)
Closing as we do not plan to implement this change in the Python extension.
- locked as resolved and limited conversation to collaborators
on Feb 12, 2023
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 conday.y.ychanged 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.