It's been proposed that we include the Go Tour in the Go binary
distributions, removing a step from a typical new user's "getting started"
We would just build the gotour binary when building the rest of the
toolchain, and include the tour
Questions: (answers I prefer are marked with an [x])
* Where should the gotour binary live?
/usr/local/go/bin: This will effectively put it in user's path. Convenient,
but heavy-handed? It's unlikely to have a name collision though. [x]
/usr/local/go/pkg/GOOS_GOARCH/gotour: This means you must run "go tool
gotour" to run the tour. Slightly more complicated, but keeps the binary
out of the user's path.
* Where should the gotour content live?
/usr/local/go/tour: the gotour can use the GOROOT baked into to the go tool
to find its content.
* What should the tour packages (pic, tree, etc) live?
In the standard library package tree: possibly the simplest approach.
Appears in godoc, might be confusing/annoying.
Alongside the tour content: would then need the gotour to set a GOPATH
before building tour programs. [x]
* How do we handle content updates?
The tour's content is improved from time to time.
Notify the user that an update is available: The gotour binary could ping
the go-tour project's downloads page to see if there's a newer version of
the tour (or even Go itself) available.
Automatically download and update tour content: Seems like a fun
engineering challenge, but is it worth the effort?
Ignore the issue: Let the user get a new version of the tour with a new
version of Go.
Your input most appreciated.