Expand description for codeQL.cli.executablePath#2441
Conversation
To match what the code actually does.
| "type": "string", | ||
| "default": "", | ||
| "markdownDescription": "Path to the CodeQL executable that should be used by the CodeQL extension. The executable is named `codeql` on Linux/Mac and `codeql.exe` on Windows. If empty, the extension will look for a CodeQL executable on your shell PATH, or if CodeQL is not on your PATH, download and manage its own CodeQL executable." | ||
| "markdownDescription": "Path to the CodeQL executable that should be used by the CodeQL extension. The executable is named `codeql` on Linux/Mac and `codeql.exe` on Windows. If empty, the extension will look for a CodeQL executable on your shell PATH, or if CodeQL is not on your PATH, download and manage its own CodeQL executable (note: if you later introduce CodeQL on your PATH, the extension will prefer a CodeQL executable it has downloaded itself)." |
There was a problem hiding this comment.
Does this only apply if the setting is empty, or also if you set this to an explicit path? I assume the first option otherwise there's no way to stop using the managed executable.
Is there any way to get the extension to stop using the managed executable and switch to the one on the path?
There was a problem hiding this comment.
Only if the VS Code setting is empty.
The logic is here
It goes in priority, and picks the first option that is set:
customCodeQlPathset in VS Code settingsextensionSpecificCodeQlPath(installation managed by extension)- Look through
PATH
Is there any way to get the extension to stop using the managed executable and switch to the one on the path?
I guess you can just delete the folders containing the CodeQL CLI downloaded by the extension, but otherwise no.
There was a problem hiding this comment.
Thanks for explaining. This makes me wonder why we use this priority because at first glance it doesn't seem to most friendly, and is hard to override at a later date. Not that I'm blaming you, or expect you to change anything. But it's interesting to highlight what the current behaviour actually is.
There was a problem hiding this comment.
It is a bit wonky. I remember at the time of developing the extension we wanted to support these three paths, but I'm not convinced the current implementation was exactly the intent 😆 All the same, documenting now sounds great, and we can figure out how to improve it later in a way that minimises breakage.
There was a problem hiding this comment.
It goes in priority, and picks the first option that is set:
1.customCodeQlPathset in VS Code settings
2.extensionSpecificCodeQlPath(installation managed by extension)
3. Look throughPATH
It looks to me that steps 2 and 3 should be reversed.
robertbrignull
left a comment
robertbrignull
left a comment
There was a problem hiding this comment.
I don't have any complaints about this PR. Documenting the current behaviour a bit more accurately is definitely good, so I think this PR is for sure beneficial.
It has highlighted that the current behaviour is a bit odd and arguably not very good in certain cases. But that doesn't mean we shouldn't document it.
4 participants
To match what the code actually does.
Checklist
ready-for-doc-reviewlabel there.