You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Referring to existing or vscode variables from values in .env file #955
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!
Brett Cannon (@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.
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.
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.
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.
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.
Activity
garu57 commentedon May 14, 2018
Brett Cannon (@brettcannon) Hi, I think this issue should be given a higher priority.
With complex project structure
.envis needed to setPYTHONPATHfor 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
.envis not shell agnostic. IMO.envshould be considered a sort of project config metadata and so platform independent. I'm I dreaming too much for.envpaths 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 commentedon May 14, 2018
Gabriele (@garu57)
Have you tried using relative paths?
PYTHONPATH=./xyz/abcgaru57 commentedon May 15, 2018
Don Jayamanne (@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
in Debugging doc.
Somehow my brain should have short circuited
python.pythonPathand don't support relative paths to becomePYTHONPATHdon'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 commentedon May 30, 2018
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
but that's sloppy and is more of workaround than a solution.
DonJayamanne commentedon May 31, 2018
Jeffrey Cochran (@jeffrey-cochran)
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
.envfiles.brettcannon commentedon Sep 20, 2018
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.