Tools on Roberto Selbach

Go 1 and the go command

Thu, 29 Mar 2012 19:25:00 +0000

Go 1 was released yesterday, so I took a small command-line programme out of its old build script and built it using only the new go command. The script did not put up much of a fight, which is usually a sign it had been waiting to retire.

From the package directory, the common operations are direct:

$ go build
$ go test
$ go install

go build compiles the package and its dependencies. go test builds and runs tests associated with it. go install places the resulting command or package object where the Go workspace expects it. Supplying an import path performs the same operation without first entering the directory.

The surprise was how much information the tool obtains from ordinary source. Import declarations already form the dependency graph. File names and build constraints identify operating-system or architecture variants. Package declarations establish the compilation unit. A separate build description for pure Go would repeat facts the compiler must know anyway.

This is not merely a shorter compiler command. The tool chooses and invokes the appropriate compiler, assembler, and linker, tracks dependencies, and gives packages a common vocabulary. That standard shape makes instructions from another project more useful: go test means the same kind of operation there as it does here.

I prefer package paths over lists of files. Building individual files can accidentally omit another file in the same package or bypass the conditions the package author expected. The package is the unit Go code is designed around, so it should also be the ordinary unit of building and testing.

There are caveats. cgo packages still bring a C toolchain and external libraries into the picture. Code generation and non-Go assets do not disappear because a pleasant command exists. The go command is deliberately opinionated, so a project that fights the package layout will not win by adding more shell around it.

The compatibility promise gives this tooling more weight. Go 1 source should remain source-compatible with later Go 1 releases, subject to the documented boundaries, while implementations improve underneath. That makes the command a stable front door rather than this week’s preferred route through the compiler tools.

My programme now builds with three unsurprising commands and no custom dependency list. Build engineering has not ended, but it has lost one excellent hiding place.

One tool for Go packages

Wed, 07 Mar 2012 17:50:00 +0000

I moved a test package this morning and expected to edit a build script. The go tool in a Go 1 development snapshot found the source by package path and did the ordinary work itself.

The basic loop is almost suspiciously short:

$ go build example/words
$ go test example/words
$ go install example/words

The surprise is not that one command has subcommands. It is that the tool understands Go packages instead of requiring me to list source files and their order. Imports describe dependencies, package directories group files, and the tool can decide what must be compiled.

This only works because the package layout is a convention shared by source and tool. A directory’s buildable Go files form a package, import paths identify dependencies, and build constraints can select platform-specific files. The command is small because the model underneath it is constrained.

I prefer this to maintaining a make rule for every package. Native libraries and generated files may still need external steps, but pure Go should not need a handwritten recital of its own import graph.

The caveat is that this is a preview from Go 1 development, not a retrospective about a finished Go 1 release. Tool behaviour and package APIs deserve checking against the snapshot in use. I am also resisting the urge to wrap the three commands in a larger script before there is any larger problem.

For this package, deleting build instructions was the feature. My build system now contains less personal folklore, which is generally where folklore is safest.

Installing Go Code With goinstall

Tue, 18 May 2010 17:36:00 +0000

The new goinstall tool removes some Makefile work from small Go packages. Given an import path on a host it recognizes, it fetches the source, builds dependencies, and installs the package in the Go tree under GOROOT. This predates the workspace layout I keep wishing into existence.

For a package hosted on GitHub I can run:

$ goinstall github.com/rselbach/lines.git

GitHub is one of the repository hosts this version knows how to fetch, provided the repository name includes the .git suffix it expects. The import path is also the package identity: source lands below $GOROOT/src/pkg/github.com/rselbach/lines.git, and the installed archive goes into the corresponding package tree below $GOROOT/pkg. There is no GOPATH here yet.

This is early machinery. Repository conventions, supported fetch methods, command flags, and even package locations are changing between weekly snapshots. I would not encode today’s behavior into a company-wide build system without pinning the toolchain and keeping the escape hatch labeled.

It also does not solve version selection. Installing the latest source from a remote location is convenient for experiments and rather less comforting for reproducing a build six months later. For serious work I still record the exact revisions of the compiler and imported code.

Even with those caveats, goinstall saves the old fetching, directory arranging, dependency chasing, and archive copying dance. The machine can have that ritual; it will invent another soon enough.