Specify syntax of using existing environment variables in .env file

[schperplata]

Issue Type: Bug

I've been looking at the docs and I think there needs to be some clarification, or there is a bug:

According to the docs, variables in .env file can be substituted by usage of <VARIABLE>=...${EXISTING_VARIABLE}... syntax. As I have discovered, this works for variables defined previously in the .env file, but not for system environment variables. System env variables need following syntax (tested): <VARIABLE>=...${env:EXISTING_SYSTEM_ENV_VARIABLE}...

Can you please specify how it should be, and update the docs?

Extension version: 2019.11.50794 VS Code version: Code 1.41.0 (9579eda04fdb3a9bba2750f15193e5fafe16b959, 2019-12-11T18:37:42.077Z) OS version: Windows_NT x64 10.0.18362

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 x 3193)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off
surface_control: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|15.89GB (6.49GB free)| |Process Argv|L:\commonPyLibs\commonPyLibsPresentation.code-workspace| |Screen Reader|no| |VM|0%|

[karthiknadig]

@schperplata Thanks for reporting this. I will need to investigate and see if we have a bug. If this is a doc issue, I will transfer it to the docs repo.

[schperplata]

Any updates here?

[karthiknadig]

@schperplata This fell off my radar. I will update with details later this week.

[karthiknadig]

Looks like this is a bug in the extension.

For repro this should work:

TESTVAR1=${PROCESSOR_IDENTIFIER}

ENVVAR=somevalue
TESTVAR2=${ENVVAR}

test_env.py:

import os

for i in range(1,3):
    print(f"TESTVAR{i}: " + os.getenv(f"TESTVAR{i}"))

launch.json:

{
    "name": "Python file",
    "type": "python",
    "request": "launch",
    "program": "${workspaceFolder}/test_env.py",
    "console": "integratedTerminal",
    "envFile": "${workspaceFolder}/.env"
}

expected output:

TESTVAR1: Intel64 Family 6 Model 61 Stepping 4, GenuineIntel
TESTVAR2: somevalue

actual output

TESTVAR1:
TESTVAR2: somevalue

[DonJayamanne]

Personally we shouldn't have added support for nested variables. It's not a standard. We keep bumping into issues here, its not supported by other tools. Too late now

[schperplata]

@DonJayamanne I don't know about what "standard" is, but for example, simple windows batch script use this approach, and I am very happy it does. Otherwise it is really easy to get messy, unreadable long strings, which are hard to inspect. Example:

SET VAR_ONE=%ROOT_DRIVE%/MY_APPS/PythonModules/Python36-64bit
SET VAR_TWO=%ROOT_DRIVE%/product_one/isys/python
SET VAR_THREE=%ROOT_DRIVE%/product_two/trunk/Utils/python
SET VAR_FOUR=%ROOT_DRIVE%/product_three/python

SET PYTHONPATH=%PYTHONPATH%;%VAR_ONE%;%VAR_TWO%;%VAR_THREE%;%VAR_FOUR%;

Imagine how PYTHONPATH would look like without support for nested variables!

[DonJayamanne]

ple windows batch script use this approach

That's a Windows batch file scrip, not a .env file. I'm referring to just a regular .env file.

To my knowledge .env files with support for nested variables doesn't exist in the most popular php, python and node packages (packages that support loading variables from .env files), including bash script with support for auto loading such variables. Hence my assumption about these being non-standard in .env files.

Please understand I'm not saying we should remove it. It's a feature that exists in the extension today, and won't be removed. I was merely expressing my opinion about this feature.

[schperplata]

I understand, I am also not trying to argue about anything. I will adapt to whatever concept you choose, as long as it is well defined and (of course) working.

I am waiting for a clarification. Let me know you need any other info/help.

[Haibao425]

@DonJayamanne I don't know about what "standard" is, but for example, simple windows batch script use this approach, and I am very happy it does. Otherwise it is really easy to get messy, unreadable long strings, which are hard to inspect. Example:

SET VAR_ONE=%ROOT_DRIVE%/MY_APPS/PythonModules/Python36-64bit
SET VAR_TWO=%ROOT_DRIVE%/product_one/isys/python
SET VAR_THREE=%ROOT_DRIVE%/product_two/trunk/Utils/python
SET VAR_FOUR=%ROOT_DRIVE%/product_three/python

SET PYTHONPATH=%PYTHONPATH%;%VAR_ONE%;%VAR_TWO%;%VAR_THREE%;%VAR_FOUR%;

Imagine how PYTHONPATH would look like without support for nested variables!

PYTHONPATH=${PYTHONPATH}:%ROOT_DRIVE%/MY_APPS/PythonModules/Python36-64bit PYTHONPATH=${PYTHONPATH}:%ROOT_DRIVE%/product_three/python PYTHONPATH=${PYTHONPATH}:%ROOT_DRIVE%/product_two/trunk/Utils/python

This way can add more paths, but %...% does not work.

[karrtikr]

Closing in favor of https://github.com/microsoft/vscode-python/issues/18307.