-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python.analysis.typeshedPaths
doesn't resolve environment variables
#2221
Comments
Thanks for the bug report! We just wanted to quickly acknowledge we received it and we will triage this as soon as we can. |
|
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 |
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 |
@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 |
I only mentioned the
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 |
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 |
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) |
This issue has been fixed in version 2022.1.1, which we've just released. You can find the changelog here: CHANGELOG.md |
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
Steps to reproduce
python.analysis.typeshedPaths
to an environment variableLogs
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: