Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

${workspaceFolder} in extraPaths resolved unexpectedly #1974

Closed
tpajenkamp-dspace opened this issue Mar 27, 2020 · 6 comments
Closed

${workspaceFolder} in extraPaths resolved unexpectedly #1974

tpajenkamp-dspace opened this issue Mar 27, 2020 · 6 comments

Comments

@tpajenkamp-dspace
Copy link

Environment data

  • Language Server version: 0.5.45.0
  • OS and version: Windows 10 1809
  • Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.7 64-bit
  • Visual Studio Code version: 1.43.2

Expected behaviour

The variable ${workspaceFolder} within the setting "python.autoComplete.extraPaths" is resolved to the correct workspace folder. For a project folder C:/temp/myproject, ${workspaceFolder}/sublibs should be resolved to C:/temp/myproject/sublibs and ${workspaceFolder}/../sublibs should be resolved to C:/temp/sublibs.

Actual behaviour

The settings

{ "python.autoComplete.extraPaths": ["${workspaceFolder}/sublibs"] }

lead to missing auto complete for sublibs, the user search path in the output is

[Info  - 14:39:21] User search paths:
[Info  - 14:39:21]     C:\temp\myproject\${workspaceFolder}\sublibs

The settings

{ "python.autoComplete.extraPaths": ["${workspaceFolder}/../sublibs"] }

"fix" the problem, the user search path in the output is

[Info  - 14:41:42] User search paths:
[Info  - 14:41:42]     C:\temp\myproject\sublibs

However, the expected path is C:\temp\sublibs.

Additional lnformation

Apparently, to get the correct workspace folder, I need to write ${workspaceFolder}/../. If ${workspaceFolder} is not followed by .., it is not resolved at all.

Of course, there is the workaround to use relative paths instead of this variable.

@jakebailey
Copy link
Member

I'm pretty sure we don't support the ${workspaceFolder} form at all (the whole "variables in config strings" thing is not consistent across editors/extensions/settings).

Does . work to refer to the workspace path?

@tpajenkamp-dspace
Copy link
Author

Alright, thanks. A simple relative path works as expected.

The use of ${workspaceFolder} in extraPaths for Visual Studio Code seems to be pretty common on the internet and I am pretty sure it worked at some point in the past. Is it something the Python Extension should/could handle?

@jakebailey
Copy link
Member

jakebailey commented Mar 27, 2020

This may have worked in the past because we didn't allow the paths to be changed at runtime, and the extension would pass them directly at startup (so would do a "lookup" through its settings provider which would have handled the replacement). But in #1492, I changed to no longer needing that constraint and instead using the LSP to ask the client for the config.

The variables are implemented by the extension as documented here: https://code.visualstudio.com/docs/python/settings-reference#_predefined-variables

But, LSP is generally between the editor and the server without the extension in the middle (who was the one who created the variables), unless it opts to intercept and start replacing.

I'm not sure where exactly we'd want to modify things. The LS is supposed to be agnostic, but the variables are vscode-python specific. The immediate solution that comes to mind is to have the extension intercept all configuration messages and forcing a replacement, but that's pretty iffy.

@jakebailey
Copy link
Member

Just remembered #1783.

@MikhailArkhipov
Copy link

Per The LS is supposed to be agnostic, but the variables are vscode-python specific., LS should not be doing VSC-specific substitutions. There are other clients beside VSC. LS knows nothing about its client and cannot assume that ${} variables have certain meaning.

@jakebailey
Copy link
Member

I'd like to at least leave #1783 open; it's possible we'll want to handle these cases for the extension (and have some initialization option in the future to indicate we should do replacements).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants