Auto-activation of `.env` Variables in New Terminals with `ms-python.python` Extension

[varun-seth]

Type: Bug

- Description: When the ms-python.python extension is enabled in VS Code, environment variables defined in a .env file within the repository are automatically and persistently set in the environment of any new terminal sessions. This behavior conflicts with the expected handling of environment variables, particularly when using the dotenv library, which only sets variables if they are not already present in the environment. As a result, changes made to the .env file are not reflected in new Python processes, leading to development frustrations.

- Expected Behavior: Suppose there is .env file in current repository's root, with one line LOG_LEVEL=DEBUG. Upon starting a new terminal session and running echo $LOG_LEVEL, the output should be empty, indicating that no environment variable LOG_LEVEL has been explicitly set in the terminal session.

- Current Behavior: Starting a new terminal session and running echo $LOG_LEVEL outputs DEBUG, showing that the LOG_LEVEL variable from the .env file has been automatically set in the terminal environment by the extension by reading it from .env file (assuming the .env file has LOG_LEVEL=DEBUG).

- Steps to Reproduce:

1. Ensure the ms-python.python extension is enabled in VS Code.
2. Create a .env file in the workspace root with a variable defined (e.g., LOG_LEVEL=DEBUG).
3. Open a new terminal session in VS Code.
4. Run echo $LOG_LEVEL.
5. Observe that the output is DEBUG, indicating the environment variable has been set automatically.

- Extension Identified: ms-python.python. The issue was confirmed through extension bisection method, conducted twice to ensure accuracy.

- Version Affected: The issue has been observed recently and is suspected to have been introduced in an update released within the last month, potentially starting from version 2024.0.0.

- Workaround: Setting the python.envFile configuration in settings.json from its default value of ${workspaceFolder}/.env to an empty string and then reloading/restarting VS Code seems to bypass the issue, indicating that the automatic setting of environment variables from the .env file is related to this configuration.

- Suggested Resolution: Consider reverting the feature that introduced the automatic setting of environment variables from the .env file in terminal sessions. Alternatively, implement a mechanism that listens for changes in the .env file and updates the environment variables in real-time.

- Additional Information:

• VS Code Version: 1.85.2 (Universal) (8b3775030ed1a69b13e4f4c628c612102e30a681)
• OS and Version: MacOS 14.3 (23D56)
• Installed Extensions: ms-python.python

- Code Snippet: ECHO $LOG_LEVEL (or any other environment variable set in the .env file)

- Dev Tools Console Errors: None

Extension version: 2024.0.1 VS Code version: Code 1.85.2 (Universal) (8b3775030ed1a69b13e4f4c628c612102e30a681, 2024-01-18T06:40:32.531Z) OS version: Darwin arm64 23.3.0 Modes:

System Info

|Item|Value| |---|---| |CPUs|Apple M1 (8 x 24)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|6, 5, 4| |Memory (System)|8.00GB (0.05GB free)| |Process Argv|setu --crash-reporter-id f7e8a5a5-70ba-4d53-8bf5-1a8152dc56fe| |Screen Reader|no| |VM|0%|

A/B Experiments

``` vsliv368cf:30146710 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes627:30244334 vscorecescf:30445987 vscod805cf:30301675 binariesv615:30325510 vsaa593cf:30376535 py29gd2263:30899288 c4g48928:30535728 azure-dev_surveyone:30548225 vscrp:30673768 2i9eh265:30646982 962ge761:30959799 9b8hh234:30694863 pythongtdpath:30769146 welcomedialogc:30910334 pythonidxpt:30866567 pythonnoceb:30805159 asynctok:30898717 pythontestfixt:30902429 pythonregdiag2:30936856 pyreplss1:30897532 pythonmypyd1:30879173 pythoncet0:30885854 pythontbext0:30879054 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 pydisww1:30959800 d34g3935:30971562 dsvsc020:30973508 ```

[karrtikr]

Please try out the pre-release version of the extension:

[karrtikr]

Possible dup of https://github.com/microsoft/vscode-python/issues/22920

[varun-seth]

Hi @karrtikr, I have tried the pre-release version v2024.3.10581547, and there also the behaviour is the same, i.e, the .env files get auto activated.

Also, you are right, this thread is a duplicate of #22920. I missed to check that this issue only occurs when using a python virtual environment. When I select the global python installation as the interpretter in VS Code, then new terminals do not auto-activate the .env files. But when I select a virtual environment (based on poetry in my case) as an interpretter, by default, the dot env files are activated in the new terminal shells.

Thank you for pointing me in the right direction. I will follow the original thread for any updates.

[karrtikr]

As a result, changes made to the .env file are not reflected in new Python processes, leading to development frustrations.

Apologies I think I misunderstood, actually I was focusing on this part of the problem. Any changes made to .env file, are now also reflected in the terminal, with https://github.com/microsoft/vscode-python/issues/22920. Does that not help the situation?

[clay-risser]

How can I prevent ms-python from loading the variables in my .env. I don't want the behavior, and if I did, this is the wrong extension to provide that. Very unpredictable behavior.

[anthonykim1]

@clay-risser try adding: "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] and see if that works.

[FelixFrizzy]

can confirm the same behaviour in my installation. I found out that installation the python extension with v2024.3.10742127 is the last one where the bug does not occur. The bug is introduced first in v2024.3.10782301. So a temporary solution is for now to switch to the last release without the bug which is then v2024.2.1 (Edit: did not work in the long run, see next comment).

[FelixFrizzy]

The problem occured again on v2024.2.1. after a restart of my laptop. Might be related to this. Adding the line to the general vscode settings.json as proposed by @anthonykim1 seems to resolve the problem for now (and hopefully persists).

[github-actions[bot]]

Hey @anthonykim1, this issue might need further attention.

@varun-seth, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[dhensen]

Wtf! Wasted 2 man hours on this 🥇 🥇 🥇 🥇

[dhensen]

Workaround that works for me is using TMUX as default profile:

🤡🤡🤡🤡🤡🤡🤡

[FelixFrizzy]

try adding: "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] and see if that works.

Did you try the workaround of anthonykim1 (cited above)? Worked for me and would be interested if it also does for you. I'm using fish as default shell.

[dhensen]

No because I want to keep that feature for when I'm running python scripts, then I want that feature to kick in. (Didnt it print on console that it had load .env? I have to admit I'm using neovim 99.9% of the time, but I had to do some frontend debugging.. so.. sorry 😂 )

[EFG-TheDevopsGuy]

On my side i've solved it by adding "python.envFile": "", into settings.json

[anthonykim1]

Closing this as not planned as adding "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] seem to provide workaround and we don't plan to provide this nested opt-out for environment variables under the python terminal environment activation experiment at the moment.

Thanks for additional approach @EFG-TheDevopsGuy here.