Scoped `${workspaceFolder:<folder>}` doesn't resolve named folders in multi-root workspace

[OmeGak]

Behaviour

Potentially related to #18650.

Expected vs. Actual

I have a multi-root workspace and I name the folders for clarity in the file explorer and search results. The ${workspaceFolder} variable, however, doesn't seem to be resolved correctly when scoped by folder name in Python settings like python.defaultInterpreterPath. Given the following folders definition in my .code-workspace file:

{
    "folders": [
        {
            "name": "named-folder",
            "path": "org/projects/project-folder"
        }
    ]
}

I expect to be able to use ${workspaceFolder:named-folder} in python.defaultInterpreterPath:

{
    "settings": {
        "python.defaultInterpreterPath": "${workspaceFolder:named-folder}/.venv/bin/python",
    }
}

Instead, ${workspaceFolder:named-folder} is not resolved at all and I'm forced to use the implicit folder name as derived from its path:

{
    "settings": {
        "python.defaultInterpreterPath": "${workspaceFolder:project-folder}/.venv/bin/python",
    }
}

This is inconsistent with how ${workspaceFolder:<folder>} is resolved in other places. For instance, ${workspaceFolder:project-folder} will not resolve in a task when the folder is named like in my example above:

{
    "tasks": {
        "version": "2.0.0",
        "tasks": [
            {
                "label": "echo",
                "type": "shell",
                "command": "echo ${workspaceFolder:project-folder}",
            }
        ]
    },
}

Variable ${workspaceFolder:project-folder} can not be resolved. No such folder 'project-folder'.

Steps to reproduce:

1. Create a multi-root workspace with at least one explicitly named folder, like in my example above.
2. Set the defaultInterpreterPath to ${workspaceFolder:<explicit-folder-name>}/<relative-path-to-python-interpreter>
3. Observe in the Python output that the ${workspaceFolder} was not resolved and, thus, no interpreter is found.

• Python version (& distribution if applicable, e.g. Anaconda): 3.9.16
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Unknown
• Value of the python.languageServer setting: Pylance

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

2023-11-09 12:16:51.050 [warning] Identifier for virt-virtualenv failed to identify /Users/ome/Code/org/projects/project-folder/${workspaceFolder:named-folder}/.venv/bin/python [Error: ENOENT: no such file or directory, scandir '/Users/ome/Code/org/projects/project-folder/${workspaceFolder:named-folder}/.venv/bin'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'scandir',
  path: '/Users/ome/Code/org/projects/project-folder/${workspaceFolder:named-folder}/.venv/bin'
}

[OmeGak]

This is not a feature-request but reporting from the built-in issue reporter in VSCode was not working.

[karrtikr]

Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority. Thanks for understanding and the patience!

[OmeGak]

I'll be happy to try and fix it myself. If I understand correctly, the bug is coming from this line of code unconditionally setting the workspace folder name to the path basename.

vscode-python/src/client/common/variables/systemVariables.ts

Lines 110 to 111 in a1fac81

	this._workspaceFolder = workspaceFolder ? workspaceFolder.uri.fsPath : rootFolder || __dirname;
	this._workspaceFolderName = Path.basename(this._workspaceFolder);

[karrtikr]

I see, so what're you expecting it to be set to?

[OmeGak]

If a folder is explicitly named, I would be expecting that one to be set as this._workspaceFolderName, rather than the basename of the path. From what I can see, WorkspaceFolder has a name attribute and I'm guessing that that is the one that stores the explicitly set name. If that is the case, my naive solution would be this:

this._workspaceFolderName = workspaceFolder.name || Path.basename(this._workspaceFolder);

[OmeGak]

On a different note, I'm surprised that there is no canonical way to resolve workspace folder names in VSCode. This leaves how to resolve the scoped ${workspaceFolder} variable up to extension authors, clearly leading to inconsistent behavior.

Also, the official documentation remains ambiguous as to how scoped ${workspaceFolder} variables should be resolved. Here, the documentation says nothing about the name attribute in workspace folders. Here, the documentation states that the name attribute in workspace folders is for display purpose in the Explorer. However, [here],(https://code.visualstudio.com/docs/editor/variables-reference#_how-can-i-know-a-variables-actual-value) the documentation implies that the canonical way to resolve variables is via echo in a task.

Then, as I mentioned in the description, if a workspace folder is named, this task will fail:

"echo ${workspaceFolder:<workspace-folder-path-basename>}"

While this one will work:

"echo ${workspaceFolder:<workspace-folder-name>}"

It may be worth eventually resolving this directly on VSCode to avoid confusion. I would imagine:

• A resolveName() or resolveScope() function in the WorkspaceFolder class that can be used by VSCode and extensions to resolve the scope canonically.
• Clarifying here that scoped ${workspaceFolder} variables are resolved with either their explicitly set name or with their path basename.
• Clarifying here that the name attribute in workspace folder is not used only for display in Explorer but also to scope ${workspaceFolder} variables.

What would you reckon is the best way to bring attention of VSCode maintainers to this?

[karrtikr]

Feel free to create an issue on VS Code's end: https://github.com/Microsoft/vscode/issues. There's a hesitancy of supporting such variables due to similar reasons mentioned in #18650 (comment). But if we mention that a similar functionality already exists: https://code.visualstudio.com/docs/editor/variables-reference#_variables-scoped-per-workspace-folder, with the support ideas you mentioned, it's more likely for them to add support.

[karrtikr]

Regarding the issue in hand, name is supposed to be same as basename according to VS Code docs:

Could you elaborate on what is the value of each in your scenario?