cmd/go: modernize the output of 'go help packages'

[matttproud]

Go version

go version go1.23-20240626-RC01 cl/646990413 +5a18e79687 X:fieldtrack,boringcrypto linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/usr/local/google/home/mtp/.cache/go-build'
GOENV='/usr/local/google/home/mtp/.config/go/env'
GOEXE=''
GOEXPERIMENT='fieldtrack,boringcrypto'
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/usr/local/google/home/mtp/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/usr/local/google/home/mtp/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/google-golang'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/google-golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23-20240626-RC01 cl/646990413 +5a18e79687 X:fieldtrack,boringcrypto'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/usr/local/google/home/mtp/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2230501016=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Run: go help packages.

What did you see happen?

The command output:

Many commands apply to a set of packages:

	go <action> [packages]

Usually, [packages] is a list of import paths.

An import path that is a rooted path or that begins with
a . or .. element is interpreted as a file system path and
denotes the package in that directory.

Otherwise, the import path P denotes the package found in
the directory DIR/src/P for some DIR listed in the GOPATH
environment variable (For more details see: 'go help gopath').

If no import paths are given, the action applies to the
package in the current directory.

There are four reserved names for paths that should not be used
for packages to be built with the go tool:

- "main" denotes the top-level package in a stand-alone executable.

- "all" expands to all packages in the main module (or workspace modules) and
their dependencies, including dependencies needed by tests of any of those. In
GOPATH mode, "all" expands to all packages found in all the GOPATH trees.

- "std" is like all but expands to just the packages in the standard
Go library.

- "cmd" expands to the Go repository's commands and their
internal libraries.

Package names that correspond to complete import paths found in the standard
library can be used as patterns without further qualification. For instance,
"fmt" refers to the standard library's package fmt, but "http" alone for
package http could not be used to refer to import path "net/http". Instead,
the complete pattern "net/http" must be used.

Import paths beginning with "cmd/" only match source code in
the Go repository.

An import path is a pattern if it includes one or more "..." wildcards,
each of which can match any string, including the empty string and
strings containing slashes. Such a pattern expands to all package
directories found in the GOPATH trees with names matching the
patterns.

To make common patterns more convenient, there are two special cases.
First, /... at the end of the pattern can match an empty string,
so that net/... matches both net and packages in its subdirectories, like net/http.
Second, any slash-separated pattern element containing a wildcard never
participates in a match of the "vendor" element in the path of a vendored
package, so that ./... does not match packages in subdirectories of
./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do.
Note, however, that a directory named vendor that itself contains code
is not a vendored package: cmd/vendor would be a command named vendor,
and the pattern cmd/... matches it.
See golang.org/s/go15vendor for more about vendoring.

An import path can also name a package to be downloaded from
a remote repository. Run 'go help importpath' for details.

Every package in a program must have a unique import path.
By convention, this is arranged by starting each path with a
unique prefix that belongs to you. For example, paths used
internally at Google all begin with 'google', and paths
denoting remote repositories begin with the path to the code,
such as 'github.com/user/repo'. Package patterns should include this prefix.
For instance, a package called 'http' residing under 'github.com/user/repo',
would be addressed with the fully-qualified pattern:
'github.com/user/repo/http'.

Packages in a program need not have unique package names,
but there are two reserved package names with special meaning.
The name main indicates a command, not a library.
Commands are built into binaries and cannot be imported.
The name documentation indicates documentation for
a non-Go program in the directory. Files in package documentation
are ignored by the go command.

As a special case, if the package list is a list of .go files from a
single directory, the command is applied to a single synthesized
package made up of exactly those files, ignoring any build constraints
in those files and ignoring any other files in the directory.

Directory and file names that begin with "." or "_" are ignored
by the go tool, as are directories named "testdata".

What did you expect to see?

While working on #69653, @robpike and I noted that the output of go help packages appears to be in need of modernization. A couple of key points regarding the output:

1. It lacks coverage of the module concept (see Gerrit review log at https://go-review.googlesource.com/c/go/+/616257 for the precise commentary on what was confusing).
2. The quotation style is internally inconsistent and inconsistent with some of the other long-form help outputs (e.g., go help testflag).
3. There are a few elements that are not quoted that should be for visual clarity.

Overall, the information feels correct for mid-2010s vintage Go but less so for today's version, so a fresh pair of eyes would help considerably.

I would be happy to contribute a secondary review of any changes to this documentation or contribute nos. 2–3. I feel less comfortable to address Rob's commentary on the modules aspect myself.

[gabyhelp]

Related Issues and Documentation

• Command go > Package lists and patterns
• Command go > Package lists and patterns
• cmd/go: go help packages is out of date #57655
• cmd/go: clarify package argument in 'go help run' summary #41830
• cmd/go: TestScript/mod_outside fails at HEAD when run after make.bash #56889 (closed)
• cmd/go: tests fail when GOROOT is stale #48698 (closed)
• cmd/go: go list should set Package.Root to the module root directory, not GOPATH #46119 (closed)
• Package build > type Package ¶
• Command go > List packages or modules
• Command go > List packages or modules

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}