my scenario was pretty much the same. I am running VSCode on Windows, wanting to used git bash as my default Terminal but after the venv got created, it was doing some weird stuff when a Terminal would open where it couldn't find the correct python interpeter in the venv/Scripts folder even though I did ctrl-shift-p a bunch of times to reset it to the python.exe there. I also wanted to make sure the activate script was run on Terminal open. I just couldn't get the debugger to work right and it kept complaining that it could not find the python interpreter, so I basically couldn't debug at all.
So for anyone who is having weird stuff happen trying to use a Git Bash Terminal in VSCode in Windows related to a python project using a virtual env, here is what I found out;
- I noticed that when I opened a new Git Bash Terminal, and looked at the $PATH variable to make sure it could find the interpreter in the venv, the path to the venv/Scripts folder would be prepended to the $PATH, but not with linux path separators like everything else in $PATH but with a Windows style path;
echo $PATH
C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv/Scripts:/c/Users/blah/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/blah/bin:/c/Program Files/Go/bin:/c/Python39/Scripts:
So whenever I would try to debug, or just even run which python, It would get confused and thought the interpreter was in here;
which python
C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv/Scripts/C/Users/blah/Documents/blah/Stock-down/Dev/this_api/venv/Scripts/python.exe
- I ran the "printenv" command in the Terminal to see what env vars were getting set and why the venv interpreter path was getting messed up. And I found a env var I didn't know existed - VIRTUAL_ENV. But I didn't know how it was getting set or where it came from. After some pain, and hunting around I found it - when you run "python -m venv venvname" to create the virtual env in the project folder, as you know, it creates the activate (and activate.bat for windows) scripts in the ./venv/Scripts folder. Inside these files this VIRTUAL_ENV variable is not only exported, but but prepended to the $PATH variable on Terminal open with the "/Scripts" folder name added in linux path style. The problem with is that it sets the VIRTUAL_ENV value with windows type path - I know its painful and wrong to do this, but I just changed it to what Git Bash is expecting, see below;
#unset irrelevant variables
deactivate nondestructive
#VIRTUAL_ENV="C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv"
VIRTUAL_ENV="/c/Users/blah/Documents/blah/Stock-down/Dev/st_api/venv"
export VIRTUAL_ENV
_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/Scripts:$PATH"
export PATH
- Now when a new Git Bash Terminal is opened it prepends the venv/Scripts path correctly to $PATH;
echo $PATH
/c/Users/blah/Documents/blah/Stock-down/Dev/st_api/venv/Scripts:/c/Users/blah/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/blah/bin:/c/Program Files/Go/bin:/c/Python39/Scripts:
- I also made a copy of the executable python.exe in the ./venv/Scripts dir and just called it "python" and now the command "which python" works and I can debug fine. I still set ctrl-shift-P when I choose the interpreter in VSCODE to "python.exe" when I just use "find" during the selection.
For more information on VIRTUAL_ENV var, see this doc -- python venv docs
It feels like jumping through a bunch of hoops I know, but this way I can open a new Git Bash Terminal, have the activate script run correctly on Terminal Open, debug, and operate normally without having to float between Git Bash AND WSL Ubuntu AND Powershell, etc.