Referring to existing or vscode variables from values in .env file

[dakotahawkins]

@DonJayamanne asked me to file this from the discussion in #944

I don't know if or how it works, I don't know if I can or how to refer to other variables inside .env (e.g. Does PYTHONPATH=${PYTHONPATH}:${workspaceFolder}/utility work?), etc.

Basically, it would make sense to me to want to do the above -- add workspace-relative paths to PYTHONPATH. It requires recursively using the existing value in PYTHONPATH as well as resolving the workspace folder.

In my use case, this is for convenience. The actual code runs in a docker container, which has it's PYTHONPATH set appropriately for it. I need VSCode to know about that so it doesn't show me quasi-existent import errors.

Maybe this is already supported, but I did it wrong. Maybe this is not supported, in which case this is a feature request. Either way, I can't tell!

[garu57]

@brettcannon Hi, I think this issue should be given a higher priority.
With complex project structure .env is needed to set PYTHONPATH for intellisense to work, but being forced to use absolute paths makes it non portable. I mean it cannot be set once for all and committed, because this would require everybody sharing the project, to checkout it into the same absolute path or to change it after checkout, with the risk of committing it again and triggering a sort of commit ping pong of .env.

Also a similar kind of problem is caused for developers working on different platforms or different shells, by the fact that .env is not shell agnostic. IMO .env should be considered a sort of project config metadata and so platform independent. I'm I dreaming too much for .env paths to be mangled depending on used shell, before being used to set env variables?

And just to prevent your query, I'd like, but I cannot help. Never programmed with js.
Thanks.

[DonJayamanne]

@garu57

but being forced to use absolute paths makes it non portable. I mean it cannot be set once for all

Have you tried using relative paths?
PYTHONPATH=./xyz/abc

[garu57]

@DonJayamanne Oh my! I guess aging is beginning to take its toll :(
It works!

It took me a while to understand why i was so sure that relative paths were not supported. I remembered having red somewhere about it and it took a bit o googling to find where.

It was this

Note: The debugger settings don't support relative paths, including when relying on the main python.pythonPath setting

in Debugging doc.
Somehow my brain should have short circuited python.pythonPath and don't support relative paths to become PYTHONPATH don't support relative paths and i took it for granted.
If I'm allowed, the name of that setting was not so wisely chosen.

Thanks, you made may day.

[jeffrey-cochran]

This is an important issue for python projects. My default sys.path is overwritten by setting PYTHONPATH in the .env file, rather than amending it. By default, I have ~15 paths in sys.path (which are lost), and I'm only using PYTHONPATH to include a few local paths specific to the project (which are gained).

This can be handled dynamically with

import sys
sys.path.append(NEWPATH)

but that's sloppy and is more of workaround than a solution.

[DonJayamanne]

@jeffrey-cochran

This is an important issue for python projects. My default sys.path is overwritten by setting PYTHONPATH in the .env file, rather than amending it. By default, I have ~15 paths in sys.path (which are lost), and I'm only using PYTHONPATH to include a few local paths specific to the project (which are gained).

Please could you provide an example, I'm unable to replicate such an issue.
If this happens users it's a bug. Making it unnecessary to support expansion of variables in .env files.

[brettcannon]

To help manage our issues and to better communicate what the team plans to work on we are closing issues that we don't plan to work on but would accept a pull request from a volunteer for. To be clear, closing this issue does not mean we won't consider a pull request for this enhancement as outlined in our contributing guide, just that the development team has no plans to work on it themselves.