Feature Request: export APIs

[hyangah]

activate can surface APIs that can be called by other extension.
Reference: https://code.visualstudio.com/api/references/vscode-api#extensions

We can consider to export information such as

• Whether the extension is fully activated
• Path to the chosen go command (if our extension starts to help easy switching between multiple go versions @mcjcloud @ianthehat)
• Settings including env vars such as GOPATH, GOMOD, ...
• Access to the Go document symbol provider (Add lenses for ginkgo to run specific tests #228 @stamblerre )

(Feel free to add the wishlist :-))

For example, see the python extension's API.
https://github.com/microsoft/vscode-python/blob/6f770f198cde6df7661a63a7026c1e10e7ae42ba/src/client/api.ts

[hyangah]

Also consider this application: #628

[firelizzard18]

I would like to see getBinPath exported. I am writing extensions that use Go binaries, and I want to respect vscode-go's relevant settings. I can use go.tools.install (command) to install tools, so the remaining piece is getBinPath.

Access to the Go document symbol provider would have solved some issues I had with the Go test explorer. I can call the symbol provider through vscode.commands.executeCommand('vscode.executeDocumentSymbolProvider', uri), but I ran into issues with activation, where my extension would be loaded and called before vscode-go had initialized the symbol provider (at least, that's what I think was happening).

[hyangah]

@firelizzard18 I discussed with a team internally. One of the concerns raised is the binary path itself may not be sufficient to run the tools in the same way the Go extension runs. The tools execution environment, flags (including those specified in the settings + flags the extension set) or cwd. For example, we plan to adopt gopls's experimental workspace module setting (or the proposed go.work) which may require the extension to determine the required flag or run commands in a gopls's super module directory outside the workspace. So, if your extension requires to mimic how the go extension would run the go command, I think either we should export all necessary info or let the go extension run the command on behalf of your request. Something like the followings. What do you all think?

• approach 1: Export all necessary info - similar to python's

export interface ExtensionAPI {
    ...
    settings: {
        /**
         * Returns the execution command corresponding to the specified resource, taking into account
         * any workspace-specific settings for the workspace to which this resource belongs.
         */
        getExecutionCommand(toolName string, resource?: Resource): { binPath: string; flags?: string[]; env?: Object; cwd?: string } | undefined;
    };
};    

• approach 2: delegate to Go extension

   // run the given tool with the provided args under the same environment the extension uses.
   // TODO: consider to take options and callback like Node.js child_process.exec.
   runTool(toolName string, args?: string[], resource?: resource): ChildProcess | undefined;

Re: extension gets ready -> How about having ready: Promise<void> in the API, that returns a Promise indicating whether this extension is ready?

export interface ExtensionAPI {
   // Promise indicating whether the extension is ready.
  ready: Promise<void>;
}

cc: @suzmue @stamblerre @findleyr @pjweinb @heschi @polinasok

[firelizzard18]

if your extension requires to mimic how the go extension would run the go command

@hyangah I don't have any strict requirements. I have two motivations: 1) I want to meet the user's expectations, and 2) I want to avoid adding code in my extensions for handling Go settings if possible.

I have two current use-cases. One is a custom debugger for scripts (which look like Go, but are executed by an interpreter, not compiled). The other is launching a long-running notebook kernel. In these two cases, I doubt I would get complaints from users if I didn't handle go.work/etc.

I do like the APIs you suggest. I personally prefer getExecutionCommand over runTool, but either would work for my purposes.

How about having ready: Promise in the API, that returns a Promise indicating whether this extension is ready?

👍

[firelizzard18]

@hyangah I updated #1642 to implement approach 1, and I tested it to ensure it works with my use-case. I left out ready because I'm not clear on how that should be implemented. const api = await vscode.extensions.getExtension('golang.go').activate() won't resolve until the (Go) extension's activation function returns.

[gopherbot]

Change https://golang.org/cl/336509 mentions this issue: src/goMain: export a small API