Skip to content

Add multiroot-workspace variable scoping for python.defaultInterpreterPath #18650

Closed
#19188
Closed
Add multiroot-workspace variable scoping for python.defaultInterpreterPath#18650
#19188
Assignees
karrtikr
Labels
area-environmentsFeatures relating to handling interpreter environmentscommunity askFeature request that the community expressed interest infeature-requestRequest for new features or functionalityverification-neededVerification of issue is requestedverifiedVerification succeeded
Milestone
May 2022

Description

@OmeGak
Alejandro Avilés (OmeGak)
opened on Mar 7, 2022

It's currently not possible to use multiroot-workspace variable scoping to configure python.defaultInterpreterPath, as Kim-Adeline Miguel (@kimadeline) mentioned in #18207 (comment).

My use case is the following. I have multiple python projects in my workspace but I want them all to use the same virtualenv, existing under one of the workspace folders. The tree structure looks like this:

/
├── python-a/
│  ├── .venv/
│  └── foo.py
├── python-b/
│  └── bar.py

To make it work with python.defaultInterpreterPath I need to configure it like this in the workspace file:

"python.defaultInterpreterPath": "${workspaceFolder}/../python-a/.venv/bin/python"

This is fragile, as it will break if python-b/ workspace folder changes its absolute path. With multiroot-workspace variable scoping it would be possible to express this dependency more robustly like this:

"python.defaultInterpreterPath": "${workspaceFolder:python-a}/.venv/bin/python"

Activity

  1. Alejandro Avilés (OmeGak)
    added
    triage-neededNeeds assignment to the proper sub-team
    feature-requestRequest for new features or functionality
    on Mar 7, 2022
  2. Karthik Nadig (karthiknadig)
    removed
    triage-neededNeeds assignment to the proper sub-team
    on Mar 8, 2022
  3. Karthik Nadig (karthiknadig)
    assigned
    Kartik Raj (karrtikr)
    on Mar 8, 2022
  4. Karthik Nadig (karthiknadig)
    added
    area-environmentsFeatures relating to handling interpreter environments
    triage
    on Mar 8, 2022
  5. Kartik Raj (karrtikr)
    added
    investigatingWe are looking into the cause of the issue
    and removed
    triage
    on Mar 8, 2022

  6. munro commented on Mar 14, 2022

    @munro
    Ryan Munro (munro)
    on Mar 14, 2022

    Alejandro Avilés (@OmeGak) I think there may be a bit over overlap here with #18674 (please up vote 😄 )

    I don't seem to have this issue specifically, but I have set this in my subworkspace's ./.vscode/settings.json:

    {
    "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python"
}

  7. SamuelT-Beslogic commented on Apr 1, 2022

    @SamuelT-Beslogic
    Samuel T. (SamuelT-Beslogic)
    on Apr 1, 2022

    One of the projects I work with is a microservices monorepo
    Each service (as well as the common/shared code library/module) have their own .venv
    As a workaround I've created a virtual environment at the root of the project and pointed defaultInterpreterPath to it "python.defaultInterpreterPath": ".venv/bin/python", so everything is installed there.
    And changed all my debug tasks commands to use the ${workspaceFolder} ("command": "cd backend/services/collect-service; poetry run ${workspaceFolder}/.venv/bin/python run.py",).

    But this really isn't the best and is bound to have issues as soon as there's version conflicts between services.
    It would be nice if VSCode devs didn't have to do that extra setup and could have scoped virtualenvs (which those using PyCharm don't have an issue with)

  8. karrtikr commented on Apr 19, 2022

    @karrtikr
    Kartik Raj (karrtikr)
    on Apr 19, 2022

    Note https://code.visualstudio.com/docs/editor/variables-reference#_variables-scoped-per-workspace-folder is currently only supported in tasks.json or launch.json (used while debugging), the use for it in settings.json is discouraged.

    Alejandro Avilés (@OmeGak) In this usecase .venv/ does not belong to the first workspace folder and is something the workspace file owns instead, so I'm wondering if the concept of ${workspaceFile} would work better instead. It can be used to access the path to the .code-workspace file.

  9. Kartik Raj (karrtikr)
    added
    needs community feedbackAwaiting community feedback
    and removed
    investigatingWe are looking into the cause of the issue
    on Apr 19, 2022

  10. karrtikr commented on Apr 19, 2022

    @karrtikr
    Kartik Raj (karrtikr)
    on Apr 19, 2022

    Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

  11. Kartik Raj (karrtikr)
    removed their assignment
    on Apr 19, 2022

  12. 1 remaining item

  13. brettcannon commented on May 12, 2022

    @brettcannon
    Brett Cannon (brettcannon)
    on May 12, 2022
    Member

    Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

    We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.

  14. Brett Cannon (brettcannon)
    added
    needs proposalNeed to make some design decisions
    community askFeature request that the community expressed interest in
    and removed
    needs community feedbackAwaiting community feedback
    on May 12, 2022

  15. karrtikr commented on May 24, 2022

    @karrtikr
    Kartik Raj (karrtikr)
    on May 24, 2022

    Alejandro Avilés (@OmeGak) Apologies for the delayed response and thanks for the insight!

    This is certainly another workaround. It's still more fragile than being able to use ${workspaceFolder:python-a}

    Two workspace folders can share the same base name as well where this does not work in its own right. However https://code.visualstudio.com/docs/editor/variables-reference#_variables-scoped-per-workspace-folder also documents this, so maybe it's not considered such a practical scenario. We'll still probably go with ${workspaceFolder:python-a} to be consistent.

    I didn't know that this practice was discouraged for extensions. I'd be curious to read more info about it, if you have any link at hand. Is workspace scoping going too far?

    Supporting such system variables in settings.json were being a problem for LSP which is probably why they aren't supported by VSCode, IIRC. I'll see if I can find any links.

  16. karthiknadig commented on May 24, 2022

    @karthiknadig
    Karthik Nadig (karthiknadig)
    on May 24, 2022
    Member

    Alejandro Avilés (@OmeGak) The reason settings.json substitutions are complicated because settings are hierarchical. In some cases there might not be a good way to resolve. Like in this scenario:
    image

    with this as a .code-workspace

    {
    "folders": [
        {
            "path": "notpython" // not a python folder
        },
        {
            "path": "python1" // the python folder that contains .pylintrc
        },
        {
            "path": "python2" // the python folder does NOT contain .pylintrc
        },
        {
            "path": "." // root workspace parent of both python1 and python2
        }
    ],
    "settings": {
        "pylint.args": ["--rcfile=${workspaceFolder}/.pylintrc"]
    }
}

    What is the right resolution here for .pylintrc for a python file under python2?

    • C:\GIT\linters\multiroot\multipython\python2\.pylintrc is incorrect because there is no such file under that workspace root, but is the correct substituion based on the variable.
    • C:\GIT\linters\multiroot\multipython\.pylintrc is the correct file, but for a file under python2 we can't find the right thing to substitute that variable.

    The issue boils down to, settings are hierarchical so substitutions are not straight forward. What works is in each folder had a settings.json of its own. Like this:
    image

    And you would not need to have variables that require substitution there, at least variables like ${workspaceFolder}.

  17. Kartik Raj (karrtikr)
    self-assigned this
    on May 24, 2022
  18. Kartik Raj (karrtikr)
    closed this as completedin #19188on May 24, 2022

  19. karrtikr commented on May 24, 2022

    @karrtikr
    Kartik Raj (karrtikr)
    on May 24, 2022

    Hi all, feature should be out in the pre-release version of the extension, use the following to try it out:

    image

  20. Kartik Raj (karrtikr)
    added
    needs PR
    verification-neededVerification of issue is requested
    and removed
    needs proposalNeed to make some design decisions
    on May 24, 2022
  21. Kartik Raj (karrtikr)
    added this to the May 2022 milestone on May 24, 2022
  22. Aaron Munger (amunger)
    added
    verifiedVerification succeeded
    on May 31, 2022
  23. github-actions
    locked as resolved and limited conversation to collaborators on Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-environmentsFeatures relating to handling interpreter environmentscommunity askFeature request that the community expressed interest infeature-requestRequest for new features or functionalityverification-neededVerification of issue is requestedverifiedVerification succeeded

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions