feat: allow workspaceFolder substition in go.alternateTools #2544
Conversation
There was a problem hiding this comment.
@pseudo-su Looks like this is your first PR contribution to this project, Thanks & Welcome!
As described in #2543 (comment), we need to resolve the path before calling getBinPathWithPreferredGopath
The util.resolvePath() function makes use of the vscode module.
Since getBinPathWithPreferredGopath gets used both from the extension and the debug adapter, we can't use code that uses the vscode module as the process that runs the debug adapter won't have access to it.
I suggest the below:
- Update
getBinPathWithPreferredGopathto take in the resolved alternate path instead of the entire mapping of alternateTools - Update the caller
getBinPathWithPreferredGopathto resolve the path upfront, and pass the resolved path.
|
|
pseudo-su
force-pushed
the
feat/allow-workspacefolder-alternatetools
branch
from
a0c2101 to
3927e9d
Compare
src/util.ts
Outdated
| return getBinPathWithPreferredGopath( | ||
| tool, | ||
| (tool === 'go') ? [] : [getToolsGopath(), getCurrentGoPath()], | ||
| resolveObjectPaths(alternateTools), |
There was a problem hiding this comment.
getBinPathWithPreferredGopath only needs to deal with the current tool.
So, instead of resolving the path for all the alternate tools, why not resolve the path for the given tool and just pass that to getBinPathWithPreferredGopath ?
i.e update getBinPathWithPreferredGopath to take alternateToolPath (a string) instead of alternateTools (a key-value map)
There was a problem hiding this comment.
That does make more sense, I'll change it now. I was focussing more on trying to figure out what I was doing wrong that's making the build fail 😄.
This is a feature I'd like, raised an issue describing it here