Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

launch.json environment variables not being passed to Python scripts #6986

Closed
duncanw opened this issue Aug 16, 2019 · 17 comments
Closed

launch.json environment variables not being passed to Python scripts #6986

duncanw opened this issue Aug 16, 2019 · 17 comments
Labels
area-debugging bug Issue identified by VS Code Team member as probable bug

Comments

@duncanw
Copy link

duncanw commented Aug 16, 2019

Environment data

  • VS Code version: 1.37.1
  • Extension version (available under the Extensions sidebar): 2019.8.30787
  • OS and version: Windows 10
  • Python version (& distribution if applicable, e.g. Anaconda): 2.7.13
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): virtualenv
  • Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version #3977): Jedi Enabled = True

Expected behaviour

Environment variables configured in launch.json should always be set when a python script is run or debugged.

Actual behaviour

Environment variables configured in launch.json are sometimes set when a python script is run or debugged. Sometimes they are not.

Steps to reproduce:

In my launch.json I have:

"configurations": [
        {
            "name": "Python: current jobs",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/beany/beany/util/reporting/weeklywip.py",
            "console": "integratedTerminal",
            "env" : {
                "SANDBOX" : 1
            }    
        }
]

When debugging this, sometimes the command line includes the SANDBOX environment variable:

PS D:\workspace\vscode> cd 'd:\workspace\vscode'; ${env:SANDBOX}='1'; ${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1'; & 'd:\workspace\vscode\beany\env\Scripts\python.exe' 'c:\Users\dunca\.vscode\extensions\ms-python.python-2019.8.29288\pythonFiles\ptvsd_launcher.py' '--default' '--client' '--host' 'localhost' '--port' '50043' 'D:\workspace\vscode/beany/beany/util/reporting/weeklywip.py'

...but sometimes it doesn't, and the environment variable isn't available to the script:

PS D:\workspace\vscode> & 'd:\workspace\vscode\beany\env\Scripts\python.exe' 'c:\Users\dunca\.vscode\extensions\ms-python.python-2019.8.29288\pythonFiles\ptvsd_launcher.py' '--default' '--client' '--host' 'localhost' '--port' '50035' 'D:\workspace\vscode/beany/beany/util/reporting/weeklywip.py'

If I edit and save weeklywip.py before running it seems more likely to include the environment variable as desired, but I haven't figured out a clear pattern. This only started happening since Visual Studio Code updated to version 1.37.0 on 2019-08-08.

@duncanw duncanw added triage-needed Needs assignment to the proper sub-team bug Issue identified by VS Code Team member as probable bug labels Aug 16, 2019
@ghost ghost removed the triage-needed Needs assignment to the proper sub-team label Aug 19, 2019
@kimadeline
Copy link

Hi @duncanw 👋 thank you for reporting this issue!

I can confirm that I can reproduce it in the following cases:

  • VS Code 1.37.1 - Python extension 2019.8.30787 - Python 2.7.10
  • VS Code 1.37.1 - Python extension 2019.8.30787 - Python 3.7.3 (venv)
  • VS Code 1.37.1 - Python extension 2019.6.24221 - Python 2.7.10
  • VS Code 1.38.0 (Insiders) - Python extension 2019.8.30787 - Python 2.7.10
  • VS Code 1.38.0 (Insiders) - Python extension 2019.8.30787 - Python 3.7.3 (venv)

A few interesting notes:

  • This behaviour only happened for the first run in the Python Debug Console terminal, subsequent runs were as expected. If the terminal was closed, then the behaviour would reappear.
  • Even though the environment variable was not added to the command being executed, it was still available to the script:

Screen Shot 2019-08-19 at 1 53 31 PM

@food2Code
Copy link

food2Code commented Feb 4, 2020

Hi @kimadeline
I've encountered this behaviour in VSCode 1.41.1.
I can confirm your findings except one case.
If one defines environment variable with value set to int, it is not available to the script at the first run:

For code:

import os

print(os.environ['TEST'])

below configuration fails at first run, works for subsequent

{
      "name": "Python: Current File 1",
      "type": "python",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "env": {
        "TEST": 1,
      }
    },

but this configuration works for every run

{
       "name": "Python: Current File 2",
      "type": "python",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "env": {
        "TEST": "1",
      }
    },

@dehai
Copy link

dehai commented May 3, 2020

Hi @kimadeline , the latest version still have this issue. detail info listed below:

  • VS Code 1.44.2 - Python extension 2020.4.76186 (27 April 2020) - Python 3.8.1 (venv)
  • OS and version: Windows 10

still can not set env variables from launch.json,
how could solve this? and when, thanks!

@kimadeline
Copy link

Hello @dehai,

We haven't addressed this bug yet, please upvote the original comment to bump up its priority.

According to the comment above yours it is possible to set environment variables in the launch.json like this:

{
       "name": "Python: Current File 2",
      "type": "python",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "env": {
        "TEST": "1",
      }
},

@dsielert
Copy link

dsielert commented Jun 2, 2020

This is a decent broken existing feature nearly a year later and still no fix ?

@pgmabv99
Copy link

Major feature remains broken ?

@jonathanmach
Copy link

jonathanmach commented Mar 30, 2021

I'm also facing the same issue.
macOS Big Sur: 11.2.3

@mrariden
Copy link

mrariden commented Jun 4, 2021

I'm having the same issue on Windows 10 Pro using VSCode 1.56.2. When I run a test using 'Run Test' the environment variables are found, but when I run a test using 'Debug Test' the environment variables are not found. The following fails in debug, but passes with run test:

def test_fails():
    import os 
    env_keys = os.environ.keys()

    assert "PYTHONDONTWRITEBYTECODE" in env_keys

And my launch.json looks like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "env": {
                "PYTHONPATH": ".;tests",
                "PYTHONDONTWRITEBYTECODE": "true"
            },
        }
    ],
}

The following test always passes and shows that environment variables are normally found:

def test_passes():
    import os 
    env_keys = os.environ.keys()

    assert "APPDATA" in env_keys

@kevcmk
Copy link

kevcmk commented Jun 16, 2021

If this won't be fixed, perhaps remove it from the documentation?

@chrisammon3000
Copy link

VS Code 1.59.0 appears to prioritize loading environment variables from the .env file in the project root first and then loads them from launch.json. In other words, every time "Start Debugging" is clicked it will update using .env first, then it will add variables that are in launch.json but not in .env. Variables in .env will overwrite launch.json.

@Lovett1991
Copy link

Same issue here... Running on windows but with vscode remote to a redhat 7 machine.

 {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            // "args": ["-t"],
            "cwd": "${fileDirname}",
            "console": "integratedTerminal",
            "environment": [
                {
                    "name":"DATA_DIR",
                    "value":"${workspaceFolder}/data"
                }
            ]
        }
os.getenv('DATA_DIR', '')

returns the default value for DATA_DIR that is set in the shell not the one explicitly set in the launch config.

@eduardolucioac
Copy link

Take a look here: https://stackoverflow.com/a/70748562/3223785 🤗 .

@YoniChechik
Copy link

The same problem exist on running .ipynb files (via interactive or jupyter extension)

@DonJayamanne
Copy link

DonJayamanne commented Apr 5, 2022

The same problem exist on running .ipynb files (via interactive or jupyter extension)

unless I'm missing something, I don't think it's the same issue, infact that's a feature request in the jupyter extension.
microsoft/vscode-jupyter#9564

@CptPicard
Copy link

Having this on 1.66.0 on Mac, the env variables actually never get passed. This is IMO pretty critical, making VSCode a no-go for my development.

@paulacamargo25
Copy link

Regarding the main issue, we only accept variables as string. This is why in the case of "SANDBOX" : 1 the value of the variable is not recognized.

If you want to use the variables in the test environment you have to add the purpose setting attribute as "debug-test" and if you want to use it in the terminal you must use ""debug-in-terminal". It is possible to set both values at once.

For example:

{
    "name": "Python: current jobs",
    "type": "python",
    "request": "launch",
    "program": "${file}",
    "console": "integratedTerminal",
    "env" : {
        "SANDBOX" : "1"
    },
    "purpose": ["debug-test", "debug-in-terminal"]    
}

@paulacamargo25
Copy link

I'm going to close the issue since the main problem has been resolved, if anyone has another bug, feel free to create another issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-debugging bug Issue identified by VS Code Team member as probable bug
Projects
None yet
Development

No branches or pull requests