python.analysis.typeshedPaths doesn't resolve environment variables

[DetachHead]

VS Code version

1.63.2

Extension version

2021.12.1559732655

OS type

Windows

OS version

10

Python distribution

python.org

Python version

3.10

Language server

Default

Expected behaviour

env variable resolves

Actual behaviour

typeshedPath c:\Users\user\basedtyping\${env:USERNAME} is not a valid directory.

Steps to reproduce

1. set python.analysis.typeshedPaths to an environment variable

   {
       "python.analysis.typeshedPaths": ["${env:USERNAME}"]
   }

2. go to the "output" tab and selete "Python Language Server"

Logs

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[karrtikr]

Thanks for the bug report! We just wanted to quickly acknowledge we received it and we will triage this as soon as we can.

[karrtikr]

python.analysis.typeshedPaths is controlled by Pylance, hence transferring to their repo.

[erictraut]

This is currently "as designed". VS Code doesn't expand these variables when it passes settings to extensions like pylance, and it provides no callback for expanding these variables. If we were to implement support for some or all of VS Code's variables, pylance would need to implement its own variable expansion mechanism, replicating the functionality in VS Code. We've talked about doing this in the past, but we've been reluctant to do so. It's worth discussing again though.

Most of the path-based settings exposed by Pylance and Pyright (e.g. "extraPaths") are intended to be relative to the workspace root directory, so path variables are not needed. I can understand, however, why it might not be so convenient to treat typeshedPaths as workspace-relative.

[DetachHead]

Most of the path-based settings exposed by Pylance and Pyright (e.g. "extraPaths") are intended to be relative to the workspace root directory, so path variables are not needed.

my use case is that i want it to be relative to wherever mypy is installed. currently i have to do this:

{
    "python.analysis.typeshedPaths": [
        ".venv/lib/site-packages/mypy/typeshed"
    ]
}

which isn't ideal because i intend to commit settings.json and there's no guarantee everybody is using a virtualenv, let alone one with the same name and location as me. ideally it would be relative to ${command:python.interpreterPath} but settings.json doesn't resolve command variables

[heejaechang]

@DetachHead by 'command' do you mean environment variable or some vscode variables?

by the way, whatever approach we takes, I dont think we will blindly expand environment variables since we are doing it on server side and it can expose some hidden env variable on server in output window.

currently, we only resolve HOME and USERNAME

[DetachHead]

by 'command' do you mean environment variable or some vscode variables?

I only mentioned the ${command:python.interpreterPath} variable to explain my use case, which I know isn’t supposed to work in settings.json, but what I did expect to work is ${VIRTUAL_ENV}

I dont think we will blindly expand environment variables since we are doing it on server side and it can expose some hidden env variable on server in output window.

That sounds like it’ll be a huge annoyance for 99% of vscode users who are just running it on their local machine. Maybe make it a server side setting or some sort so that servers running vscode can turn it off?

Besides, other settings seem to expand any environment variable anyway so what’s the harm in making this one consistent with the others

regardless there seems to be no documentation explaining in what circumstances certain kinds of variables get resolved and others don’t. Though that problem isn’t exclusive to the python plugin

[heejaechang]

alright, we probably need to discuss about it more than. @judej @savannahostrowski

by the way, we can add VIRTUAL_ENV to the list of env variable we resolve

[heejaechang]

I added server to expand VIRTUAL_ENV from the env variable where vscode is running. (don't get confused by the one selected from interpreter selector)

[bschnurr]

This issue has been fixed in version 2022.1.1, which we've just released. You can find the changelog here: CHANGELOG.md