vscode-variables only expanded in some environment vars from .env file

Environment data

• VS Code version: 1.50.1
• Extension version (available under the Extensions sidebar): v2020.9.114305
• OS and version: linux, ubuntu 20.04
• Python version (& distribution if applicable, e.g. Anaconda): python3.8.5, from normal ubuntu20.04 repos. Using a per-project venv (which is working fine).
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): venv
• Relevant/affected Python packages and their versions: I do have a few packages installed in the venv, but I don’t believe there is any relation here.
• Relevant/affected Python-related VS Code extensions and their versions: I’ve disabled all extensions expect python to reproduce this.
• Value of the python.languageServer setting: I don’t have this in alt-x. Is this a windows-only setting?

[NOTE: If you suspect that your issue is related to the Microsoft Python Language Server (python.languageServer: 'Microsoft'), please download our new language server Pylance from the VS Code marketplace to see if that fixes your issue]

Expected behaviour

all variables in python.envFile are loaded into the process WITH normal vscode variable expansion.

Actual behaviour

All variables from the .env file are present in the python process’s os.envar, but only certain variables have the vscode variables properly expanded.

the particular vscode variable I need expanded is ${workspaceFolder}

as an example, PYTHONPATH is correctly expanded, FOOBAR1 env var appears to have the vscode variable expanded as "".

Steps to reproduce:

1. added python project to a new workspace.
2. setup python in the project. As best i can tell this is working.
   • `“python.pythonPath”: “${workspaceFolder}/venv/bin/python3”
   • “python.envFile”: “${workspaceFolder}/.vscode/vscode.env”
3. create an the env file FOOBAR1=${workspaceFolder}/foobar1.asdf PYTHONPATH=${workspaceFolder}/backend/src:${workspaceFolder}/tools/libraries:/tmp/foobar-invalid2:${env:PYTHONPATH}
   • note, also added trivial code to the module I’m running to observe this; just print('ing all vars in os.environ. Output below.
4. run the python (I have no reason to believe this is involved since I get some expansion, but in case it’s relevant:
   • add a new run config { "name": "Python: Current File", “type”: “python”, “request”: “launch”, program": “${file}”, “console”: “integratedTerminal” }, `
   • Run a file with an if __name__=="__main__":
   • the module executes as expected AFAICT
5. observe the env vars via print('s added above:
   • FOOBAR1=/foobar1.asdf
     • ^^ ${workspaceFolder} is expanded as ""
   • PYTHONPATH=/home/<omitted>/backend/src:/home/<omitted>/tools/libraries:/tmp/foobar-invalid2:
     • ^^ but it is expanded correctly here??
   • note that I can change both variables in the file (FOOBAR1–>FOOBAR1) and see it updated live, so the file IS being picked up.

Logs

can provide, don’t know location.

[mcow]

I just looked up a comment I made elsewhere, from this past August, recommending ${workspaceFolder} in a .env file. I can’t be 100% sure that I had it working correctly but I think I did, then. It is not working now, as this bug attests. As a workaround, I am now using ${env:HOME}/path/to/workspace. It is annoying that I need to use .env to set PYTHONPATH for debugging, but in terminal.integrated.env.linux in order to work from the “Run arrow icon at the top of the source window” (is there an actual name for that?). Inconsistent support in the two contexts just makes that worse.

[brettcannon]

@mcow sorry to hear your coworkers are switching, but unfortunately we have other things taking up all our development time right now. We do plan to tackle this and path-related issues in general, but I have no ETA on that work.