proposal: cmd/go: allow "go run ."

[broady]

Currently, go run requires Go files as arguments. It's useful for quickly running Go programs, but has been discouraged by many people because dependent packages are not installed. With the changes to build caching in Go 1.10, I propose we simplify usage of go run to encourage more use of it.

A rundown of use cases and how this change would improve the user experience:

1. Program with one file (e.g., one-off scripts, go generate scripts)

   • go run script.go
   • After: unchanged
   • Improvement: a little more flexibility if it's the only .go file in the directory.

2. Program with more than one file, with no tests

   • Before: go run *.go
   • After: go run
   • Improvement: minimal

3. Program with more than one file, where test files are also in the same directory.

   • Before: go run !(*_test).go or go run main.go a.go b.go
   • After: go run
   • Improvement: huge. I had to look up this glob syntax.

4. Program that accepts arguments

   • Before: go run main.go arg1 arg2
   • After: go run -- arg1 arg2
   • Improvement: same as 1, 2, 3
   • NOTE: to prevent collisions of flags between cmd/go and the user's program, we should probably require the -- separator when filenames are omitted.

5. Program that accepts Go filenames as arguments

   • Before: go run main.go other.go -- foo.go
   • After: go run -- foo.go
   • Improvement: same as 1, 2, 3

6. Program with build tags

   • Before: go build -tags -o a && ./a && rm ./a (go run ignores build tags on the files passed in)
   • After: go run -tags foo
   • Improvement: makes what is basically impossible possible. But this isn't a common use case.

Also, perhaps a package path should be allowed as an argument, which would better mirror go build:

go run golang.org/x/tools/cmd/godoc -http=:6060

[cespare]

FWIW, I'm one of those people that discourages the use of go run and my reasoning has little to do with caching dependent packages. From what I've seen, when go run is used for multiple .go files or for any of the more complex use cases like the ones you've listed here, it's generally by new Gophers that haven't really internalized how packages work yet. I don't see how an easier-to-use go run is better than go build/go install for these sorts of things.

• Before: go run script.go -- foo.go
• After: go run -- foo.go

How does go run know to run script.go in this case, if there are other .go files?

[broady]

I don't see how an easier-to-use go run is better than go build/go install for these sorts of things.

go run is already in many ways better than go build/go install for one-off/ad-hoc invocations.
go build is decent, but requires you to clean up the binary after you're done. go install is even worse: the user must understand that the binary ends up in $GOPATH/bin.

How does go run know to run script.go in this case, if there are other .go files?

Use case 5 is when there are no other Go files. If there are other Go files, that's use case 1. Updated script.go to main.go to clarify.

Here's a concrete example that might help you understand my viewpoint:
https://github.com/GoogleCloudPlatform/golang-samples/tree/master/vision/detect

This program is split across two files, and there's also a test file. There's two choices to help people run this program (note that they may not be experienced Go developers, who fully understand how packages, go build, go install all work).

There are a few choices to tell people how to run the program:

1. go build && ./detect [args] && rm detect
2. go install && $GOPATH/bin/detect [args] && rm $GOPATH/bin/detect
3. go run detect.go main.go [args]

As you can see, I chose the third option. It'd be much nicer for this to simply be go run -- [args], I think.

[myitcv]

@broady

go install && $GOPATH/bin/detect [args] && rm $GOPATH/bin/detect

The problem here is when GOPATH is a path list; hence you can't rely on $GOPATH/bin/xyz.

I started a thread on golang-nuts with what I think is similar motivation to this issue:

https://groups.google.com/d/msg/golang-nuts/4C_Rd_JJZVU/UdqRePeMBwAJ

@cznic raised some concerns about overloading the run subcommand which I can understand, hence I sort of morphed the suggestion into a new subcommand exec. But then there wasn't much other interest.

As you point out, with the build caching changes in Go 1.10, I would guess that go exec would be even easier to implement/support?

[rsc]

Related:

• "go run" should be able to run a directory #20432 ("go run" should be able to run a directory)
• cmd/go: allow "go run" to run command in current directory #5164 (cmd/go: allow "go run" to run command in current directory)
• cmd/go: run with "--" leaks "--" into os.Args #10241 (cmd/go: run with "--" leaks "--" into os.Args)
• cmd/go: run passes arguments to binary incorrectly #10761 (cmd/go: run passes arguments to binary incorrectly)

I'm pretty sure there's old discussion about whether #! should be ignored in code that played into these too but I can't find the ones that related to go run. (I don't think we should ignore #! lines.)

Potential design based on discussion with proposal review:

go run [go flags] [single-package-or-*.go-list] [subprocess flags]

If you specify a package (even "."), then it's clear how to split the two possible flag lists.
If you don't specify a package, we should probably not repeat 'go test's mistake and try to split the flags magically. So then we have to decide whether

go run -flag

means -flag goes to the go command or to the subprocess (the decision should not depend on exactly which flag it is). For consistency with go build etc we should probably make the default be go flags. That seems less surprising. To specify subprocess flags, fill in [single-package-or-*.go-list] with "." meaning the package in the current directory.

Today:

go run x.go -x # go build -o a.out x.go && ./a.out -x
go run x.go hello # go build -o a.out x.go && ./a.out hello
go run x.go -- -x # go build -o a.out x.go && ./a.out -- -x

Maybe tomorrow:

go run # go build -o a.out . && ./a.out
go run -v # go build -v -o a.out . && ./a.out
go run . -v # go build -o a.out . && ./a.out -v
go run -v . -x # go build -v -o a.out . && ./a.out -x
go run -v -- -x # go build -v -o a.out . && ./a.out -- -x
go run cmd/gofmt -help # go build -o a.out cmd/gofmt && ./a.out -help

This would change @broady's 4 and 5 above to use "." instead of "--", but that's much easier to explain ("." is a valid argument to build, test, etc).

[rsc]

Actually the default really must be that without a package list the flags are all for the go command. If they were all for the subprocess then there would be ambiguities due to not knowing which of the subprocess flags took arguments. For example if the subprocess took a -x=string flag, then

go run -x=string

would look like not having a package, but you'd think an equivalent command would be:

go run -x string

which would incorrectly look like a go flag followed by a package name.

Defining that the first flags are always go flags avoids this ambiguity.

[rsc]

Based on discussion with proposal-review again this week, accepting proposal as detailed in #22726 (comment). I will take a look at this for Go 1.11.

[broady]

Back from vacation. I had done a little more thinking before you posted the comments above, and came to a similar (but more strict) conclusion: that "go run" should require a package name (or list of files) to remove all ambiguity.

So:

go run # error, must provide package name or list of files
go run . # go build -o a.out . && ./a.out
go run -v . # go build -v -o a.out . && ./a.out
go run . -v # go build -o a.out . && ./a.out -v
go run -v . -x # go build -v -o a.out . && ./a.out -x
go run -v . -- -x # go build -v -o a.out . && ./a.out -- -x
go run cmd/gofmt -help # go build -o a.out cmd/gofmt && ./a.out -help

I'm not certain that the gain in precision is worth requiring the argument, and think that the rules you described balance ease of use with precision well enough.