|author||Bryan C. Mills <email@example.com>||Fri Feb 07 13:55:53 2020 -0500|
|committer||Bryan C. Mills <firstname.lastname@example.org>||Fri Feb 07 19:21:55 2020 +0000|
cmd/txtar: add a minimal command for creating txtar archives I've been working on a design doc for a lazy module loading algorithm, and I want to be able to present examples as txtar archives (because that's what the eventual integration tests will be anyway). But I also want to be able to run the 'go' command interactively in those archives (to figure out what the behavior today is and how it would change), and if I decide that I need to change the example it becomes tedious to edit it locally and then repackage it. This change adds a minimal binary for constructing and unpacking archives. The comment section (which is usually relevant to the test) and the archive itself are passed on stdin and stdout, and files are read or written relative to the working directory of the command. A list of files and/or directories can be passed explicitly at creation time (to bypass extraneous files such as Git metadata). Since the cmd/go tests in many cases use paths relative to the $WORK or $GOPATH variables, this binary expands shell variables during both creation and extraction. A similar set of utility programs can be found in github.com/rogpeppe/go-internal/cmd. While those programs are useful, they are somewhat more flag-intensive, do not support shell-escaped paths or explicit file lists, and do not extract or accept comment text on stdio and stdout. Change-Id: Ibfd2f7b308151b5588bba14c9d66c59453fbdbe0 Reviewed-on: https://go-review.googlesource.com/c/exp/+/218498 Run-TryBot: Bryan C. Mills <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Jay Conrod <email@example.com>
This subrepository holds experimental and deprecated (in the
old directory) packages.
The idea for this subrepository originated as the
pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to
go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)