Add commands for executing go build, go test and go install

[ppone]

On OS X 11.11.1, most of the Go commands seem to be working, however Go Build on save does not work.

Go Path seems to be correct.

[lukehoban]

The build on save should report compilation errors as red squiggles and in the bar at the bottom left of the screen. Are you not seeing errors being reported?

The build on save does not produce a binary or any other artifact. You can use VS Code's tasks to hook up a build command to run go build, go install, go test, etc. See https://code.visualstudio.com/Docs/editor/tasks.

[ppone]

If there is an error in the code I see red squiggles, so yes if the code has errors I see them in the IDE.

I was under the impression it would generate a binary with Go Build, but your saying that it is working correctly as Build on Save lets you know if there are errors.

It would be great if "Go for Visual Studio Code" could include those tasks like Go Build, etc like GoSublime on SublimeText.

Off topic, VS Code is fast. It is up there IMO with SublimeText.

Thanks,

Parag

On Nov 18, 2015, at 3:59 PM, Luke Hoban notifications@github.com wrote:

The build on save should report compilation errors as red squiggles and in the bar at the bottom left of the screen. Are you not seeing errors being reported?

The build on save does not produce a binary or any other artifact. You can use VS Code's tasks to hook up a build command to run go build, go install, go test, etc. See https://code.visualstudio.com/Docs/editor/tasks https://code.visualstudio.com/Docs/editor/tasks.

—
Reply to this email directly or view it on GitHub #21 (comment).

[lukehoban]

@ppone Makes sense. Let's keep this issue to track adding more integration with go build, go install, go run and go test.

There are likely two ways to include these:

1. Add new commands to the command palette for Go: Build, Go: Test, etc. which operate either in the context of the opened workspace or the current file?
2. Provide a command which automatically generates VS Code tasks for these in a .vscode/tasks.json in your current workspace.

The second is more native to VS Code, but likely the first is a convenient shortcut to this.

Thoughts?

[ppone]

The first option I think will the best for users.

The beauty of a ideal IDE is that CMD+Shift+P would all of the Go tooling, such that you never need to leave the IDE.

On Nov 18, 2015, at 4:28 PM, Luke Hoban notifications@github.com wrote:

@ppone https://github.com/ppone Makes sense. Let's keep this issue to track adding more integration with go build, go install, go run and go test.

There are likely two ways to include these:

Add new commands to the command palette for Go: Build, Go: Test, etc. which operate either in the context of the opened workspace or the current file?
Provide a command which automatically generates VS Code tasks for these in a .vscode/tasks.json in your current workspace.
The second is more native to VS Code, but likely the first is a convenient shortcut to this.

Thoughts?

—
Reply to this email directly or view it on GitHub #21 (comment).

[ahmetb]

+1 for first option

[MattMattV]

Why not providing the two options ? Some users coming from Sublime Text will find the first option more intuitive, and the second will be more useful for those who master VSCode like pros !

[lukehoban]

@Mistermatt007 Agreed - I think both can be supported.

[pootow]

How to vote up this feature?

[lukehoban]

Question for folks looking for (1).

Should Go: Build invoke the build in the root of the workspace that is opened in Code, or in the folder containing the file currently open in the active text buffer? Both feel potentially wrong in some set of cases.

[MattMattV]

Maybe when you invoke the command, a second menu should ask you what to build when it's ambigous

[lukehoban]

Well it will frequently be ambiguous and I expect a second menu is more friction than is desired in this workflow. Option (2) is also available for full configuration of build/test tasks.

My inclination is to go with the active document's folder (even if it is not a .go file).

[ironcladlou]

@lukehoban

I'm the author of GoTools for Sublime and have been evaluating vscode-go. GoTools supports some test related commands I use many times a day and simply can't work without:

• Run test at cursor
• Run tests in package
• Run last test

You can see how I implement these in the source. Maybe there's something which could save you some time coming up with an equivalent implementation.

Question for folks looking for (1).

Should Go: Build invoke the build in the root of the workspace that is opened in Code, or in the folder containing the file currently open in the active text buffer? Both feel potentially wrong in some set of cases.

The way I handled this in GoTools is to require users to define the package structure on a project basis. I also only support go install for the build task based on the defined project structure. For example:

• The trivial example from the README: ExampleProject.sublime-project
• A project file for hacking on Google's Kubernetes: kubernetes.sublime-project
• A project file for hacking on Red Hat's OpenShift: origin.sublime-project

The latter two are good examples of dealing with the complexity of configuring extremely large Go projects.

Related for future reference: anything that requires a package scope (like oracle or go install) seems likely to thwart attempts at inference using just the workspace directory structure and files. For example, the tooling is not going to be able to infer that my main package is github.com/openshift/origin/cmd/openshift for go install or analytics. The projects I work with also produce multiple binaries. Some sort of configuration in that regard seems inevitable.

Offtopic: Thanks for your work on this plugin, it seems really promising so far, and I'm eager to help out. I think I've hit the limit of what Sublime can be expected to provide with its limited API and UI (especially with Delve.) This project has me thinking about learning TypeScript and redirecting my efforts...

cc @stevekuznetsov @pmorie

[lukehoban]

@ironcladlou Thanks for weighing in here.

Definitely agree on the additional commands for running tests - those make sense and happy to take a look at the implementations in GoTools for inspiration.

I had hoped to keep the project configuration requirements light here, and rely mostly on the workspace as the context for "global" operations (like find-all-references). But it sounds like you have experience with cases where that is not practical.

I'm curious why more of this can't be automatically discovered within a workspace context though (go test ./... for example).

I also wonder whether (to the extent that additional project configuration is needed) these things should be configured at the workspace settings level, tasks level, or really need a new project file (akin to .sublime-project).

Do you think it's possible to have smart defaults without any of this additional configuration and then allow this configuration to override those defaults?

[stevekuznetsov]

I'm not sure smart defaults are possible with minimal effort - for instance, setting $GOPATH is often a hassle. In OpenShift Origin we have to include three things: our source, our build output files, and our stored, version-locked dependencies that we embed. I'm not sure that figuring those paths out for any arbitrary project would be easy.

[ironcladlou]

You can certainly use wildcards with test and build as very broad operations, but to break it down a little by task...

Tests:

Running all tests with wildcards takes too long when working on a single test. Thoughts on the other test variants:

1. Running tests in the current file's package might be inferred through directory walking relative to the test file
2. Running the test at cursor builds upon 1 and implies discovery of the function name at cursor to feed as a regex to go test
3. For tests with tags, the tags for the current test can be parsed from the file's header and automatically included in the test execution

Builds:

Running go build for a single file might be fine for a simple narrow analysis, but to catch all errors across your project introduced by a change to a given file, it's necessary to compile your main programs which depend upon it. Problems I see so far:

1. Using build is slow; using install is necessary to benefit from the compiler cache
2. Even if you switch to install, using wildcards can catch more than you intend in a complex project. For example, I work with projects that contain one-off example go programs and utilities, often co-located in the same directory outside of a package structure, intended to be used with go run only. Using wildcards will try building those as a single package which always fails.

I'm pretty sure conventions/inference can get us very far with the test executions, but I haven't yet thought of a way to solve the build issues other than allowing the user to specify a list of packages to build. Perhaps ./... could be the default (which would probably work for simply structured programs) combined with a package list configuration.

[ironcladlou]

It seems like I could implement go install for my project by defining a custom task and problem matcher. It's not entirely clear to me yet when it's appropriate to just have users make tasks vs. providing a configurable command from the plugin (followup: could a configurable command be supplied which could be incorporated in the task? e.g. an install command which accepts the package list from task arguments but which handles GOPATH and the command line construction automatically).

Still trying to wrap my head around VSCode tasks and internals...

[klaidliadon]

It would be useful also add go generate ./...

[ITSecMedia]

Can't wait until the new features are added.

[mohitranka]

Any ETA on this functionality to be available in the stable?

[ironcladlou]

I was messing around tonight to see if I could get tasks working for go install, but the task environment always has an incorrect GOPATH (it's apparently not using process.env set by the plugin and it's also not using the GOPATH I exported before when trying code from a terminal on OS X 10.11.3).

[lukehoban]

@ironcladlou I am seeing that the go.gopath setting is not being picked up in tasks (unfortunately I don't think there's any way to handle that), but that the GOPATH from the shell which launched code is being picked up. (I'm on OS X 10.11.4).

You can force the GOPATH setting with something like this:

{
    "version": "0.1.0",
    "command": "go",
    "isShellCommand": true,
    "showOutput": "silent",
    "options": {
        "env": {
            "GOPATH": "/Users/lukeh/dd/go"
        }
    },
    "tasks": [
        {
            "taskName": "install",
            "args": [ "-v", "./..."],
            "isBuildCommand": true
        },
        {
            "taskName": "test",
            "args": [ "-v", "./..."],
            "isTestCommand": true
        }
    ]
}

[lukehoban]

Added a note about the path forward for this here: #134 (comment).

[ironcladlou]

This was a good issue to get a lot of discussions and work started. I now propose we close this issue in favor of #287 (for install), #73 (for run), #263 (for generate), and a new issue (if desired) for build.

[lukehoban]

@ironcladlou Agreed, I'll go ahead and close this. Feel free to open a new issue for build, or else it can just be a presumed feature of adding go install per #287.

[fervic]

... and another issue for go test 😉

[ironcladlou]

@fervic

... and another issue for go test

Is there some testing need not met by the existing go test support?

[fervic]

Sorry, didn't know go test support is already there, saw it mentioned in
this issue's subject but didn't see it in the by-command ticket breakdown
of the previous comment.
On Apr 14, 2016 6:33 PM, "Dan Mace" notifications@github.com wrote:

@fervic https://github.com/fervic

... and another issue for go test

Is there some testing need not met by the existing go test support?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#21 (comment)

[covrom]

To build package on current opened file path, add this build task:

{
"version": "0.1.0",
"isShellCommand": true,
"showOutput": "always",
"command": "go",
"echoCommand": true ,
"options": {
    "cwd": "${fileDirname}"
},
"tasks": [
    {
        "taskName": "build",
        "args": [
            "build",
            "-x"
        ],
        "isBuildCommand": true,
        "suppressTaskName": true
    }
]
}

[ShineSmile]

@covrom I tried to change to current opened file's directory several times. I had considered cwd is readonly.
Thx.

[watchpoints]

Installing 8 tools at D:\code\wcy\mygo\bin
go-outline
go-symbols
guru
gorename
impl
goreturns
golint
gotests

Installing github.com/ramya-rao-a/go-outline FAILED
Installing github.com/acroca/go-symbols FAILED
Installing golang.org/x/tools/cmd/guru FAILED
Installing golang.org/x/tools/cmd/gorename FAILED
Installing github.com/josharian/impl FAILED
Installing sourcegraph.com/sqs/goreturns FAILED