proposal: github.com/golang/go/go/src/cmd/go

[eighty4]

Go Workspace Commands

The new workspace features are great. I'd like to extend the capabilities of the go binary to use existing features across multiple modules in a workspace with convenience commands. There are two types of enhancements I wanted to propose:

• running commands like go test or go mod tidy in every module of a workspace by extending the subcommands of go work
• running a go get or similar command from a workspace root dir and applying that command to a module referenced in go.work

Go Work Test

go work test [build/test flags] [test pattern] [build/test flags & test binary flags]

go work test would compile and run each tests for all modules listed in go.work. I changed [packages] to [test pattern] in the command as go work test would already resolve explicitly to the workspace modules which packages' tests would be run. Build and test flags would be:

• -exec xprog
• -c
• -args
• -json output already supplies Package and could be extended to include the workspace path

Forgive me if this capability is already present. I could not figure out how to use the [packages] portion of go test and I'm still fuzzy on ./.... I'm currently using go list -f '{{.Dir}}' -m | xargs go test to run all workspace tests.

Go Work Tidy

go work tidy [-e] [-v] [-go=version] [-compat=version]

All existing flags would be applicable to running a go mod tidy across multiple modules at the same time. Execution and output could either be parallel and prepended by module or could be ran sequentially and categorized in the terminal with the module name.

I don't think it's confusing taxonomy jumbling go work tidy out of a command that runs a tidying operation on modules. It's a well known concept within the go community and it would be readily grasped as a command that performs a go mod tidy operation within the context of a workspace.

Here is an example of go mod tidy use that could more succinctly be performed with go work tidy.

Go Work Get

go ? get ?

I'm still not sure how it would be best to improve workspace workflows with go get. It would be nice to be able to perform go get within any module of a workspace without extra cd commands. From a directory containing a go.work file that uses ./module:

• go get -m ./module github.com/get/package
• go work get ./module github.com/get/package
• go work mod ./module get github.com/get/package
• go work get -m ./module github.com/get/package

[seankhliao]

Test shouldn't be special enough to break out of #50745

Tidy doesn't make sense as a workspace command until #50750 has some form of resolution.

The go get commands are equivalent to go get -C ./module example.com

[eighty4]

It didn't seem like #50750 was wanting to perform go mod tidy as an isolated unit of work for each module of a workspace. I really couldn't understand the expectation from the issue.

The key part of proposing additional dedicated subcommands for go work is about accessibility. For example, there's no capital C in go help get and I'm not sure if that comment references an implemented or proposed feature. Discoverability of module or workspace work flows is exclusive to GH discussions (where I learned how to use go list and xargs to run tests).

Having access to these utilities and docs from go work adds discoverability for people new to the features and new to go in general who might not be familiar with the intricacies of go mod tidy and go get. I've personally used golang recreationally for a decade and only used go mod tidy for the first time this year.