Skip to content

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

Closed

Description

Don Jayamanne (@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!

Activity

  1. garu57 commented on May 14, 2018

    @garu57

    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.

  2. DonJayamanne commented on May 14, 2018

    @DonJayamanne

    Gabriele (@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

  3. garu57 commented on May 15, 2018

    @garu57

    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

    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.

  4. jeffrey-cochran commented on May 30, 2018

    @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.

  5. DonJayamanne commented on May 31, 2018

    @DonJayamanne

    Jeffrey Cochran (@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.

  6. brettcannon commented on Sep 20, 2018

    @brettcannon
    Member

    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.

  7. locked as resolved and limited conversation to collaborators on Oct 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions