Tasks with active venv get source /path/to/activate as stdin

[yumasheta]

Environment data

• VS Code version:

  • Version: 1.41.1
  • Commit: 26076a4de974ead31f97692a0d32f90d735645c0
  • Date: 2019-12-18T15:04:31.999Z
  • Electron: 6.1.5
  • Chrome: 76.0.3809.146
  • Node.js: 12.4.0
  • V8: 7.6.303.31-electron.0
  • OS: Linux x64 5.4.7-arch1-1

• Python Extension version: 2019.11.50794

• Python version: 3.8.1

• Type of virtual environment: venv

Expected behaviour

When configuring a task via the .vscode/tasks.json file and running it, the terminal used should change to the venv set and stdin should be empty for the commands in the task configuration to use (eg. when using read in a bash script).

Actual behaviour

When running a task, (via command palette: 'Run Task') stdin is filled with the command:
source /path/to/activate. If the command set in the task, reads from stdin, it gets this string.
This only happens if the terminal window is fresh (previous terminals were killed). For repeated runs of the task in the same terminal (without setting presentation{"panel":"new"}), this behaviour is not observed.

The command to load the venv (via source [...]/activate) should not be executed after the command from the task, but instead at the very beginning. It also should not fill up stdin.

When not having set a venv interpreter, the issue is not present.

Steps to reproduce:

zipped archive of the files and venv:
files.zip

1. create a new venv
2. open the folder in vscode
3. set the interpreter to the new venv
4. add these three files:

./a.py

print(input("your input: "))

./b.sh

read a
echo $a

echo $VIRTUAL_ENV

.vscode/tasks.json

{
   "version": "2.0.0",
    "tasks": [
        {
            "label": "python",
            "type": "shell",
            "command": "${config:python.pythonPath} a.py",
            "presentation": {
                "focus": true,
                "panel": "new"
            },
            "problemMatcher": []
        },
        {
            "label": "bash",
            "type": "shell",
            "command": "./b.sh",
            "presentation": {
                "focus": true,
                "panel": "new"
            },
            "problemMatcher": []
        }
    ]
}

Now use the command palette and run either task ('python' or 'bash').
When running the task in a fresh terminal, the output will be:
python:

> Executing task: cleanvenv/bin/python3 a.py <

your input: source /tmp/files/cleanvenv/bin/activate
source /tmp/files/cleanvenv/bin/activate

Press any key to close the terminal.

bash:

> Executing task: ./b.sh <

source /tmp/files/cleanvenv/bin/activate
source /tmp/files/cleanvenv/bin/activate

Press any key to close the terminal.

For the bash version, there is also no environment variable $VIRTUAL_ENV set.

Remarks

I hope the explanations were clear enough.
I am very new to issue reporting. Please let me know, if I missed anything.

[brettcannon]

Thanks for the bug report! We just wanted to quickly acknowledge we received it and we will triage this as soon as we can.

[karthiknadig]

@yumasheta we are trying to see if we can get rid of conda source usage entirely (see #8864). Likely result of that investigation would be that we will remove conda source from most cases except where is might be absolutely needed. I think that should address this scenario.

@luabud This is an item that we have to discus with VSCode. We need a way to know if a terminal was started as a part of a task or if user created the terminal using the + button. This is so we know to use the right commands if the terminal has to be be activated.

[yumasheta]

@karthiknadig I am not really familiar with conda. But I suppose, it uses the same source .../activate mechanism as standard python virtual environments.
I just want to clarify, that I do not use conda, but use standard python venv.

[karthiknadig]

@yumasheta Ah yes. Sorry. The problem is as i described in the second paragraph. We have no way to hook into when the terminal gets created to know when to activate. This usually means if VSCode gets to it first, then it runs the command first and we activate later. You may see this problem while debugging as well, the activation command sometimes occurs after the debugger command is executed.

[karthiknadig]

This issue should be resolved when we support #11039. This way we will not be sending the activate command to terminal at all. Closing this in favor of the above issue.