Paul Jolly

@twpayne it's precisely because it's been merged that we need this issue 😄 - i.e. we need to "keep up to date" with the upstream.

cc @rogpeppe - note that per https://go-review.googlesource.com/c/go/+/162437 this has not been accepted upstream. So I think it comes down to working out whether we want to extend the API here...

Thanks - can you give a bit more background on what it is you're trying to do here, and exactly which part of the package API you'd therefore use? Thanks

Thanks - can you give a bit more background on what it is you're trying to do here, and exactly which part of the package API you'd therefore use? Thanks

@mvdan - do you use `golang.org/dl/go*`? I'm afraid I don't use it. Instead I have full installs and use process mount namespaces to flip between versions (largely to avoid any...

cc @rogpeppe

Would `go list` (with suitable flags) not suffice here, for both? _I say that assuming shell completion can be made to work given the line-based output of a command_

`go list -f` can probably give us whatever we need from a completions perspective, but the status showing "dirty" for `-vcs` hacks would definitely be useful.

I'd certainly use this, so it would get my vote!

For control over the location of where `gohack` puts code, set `GOHACK`. FWIW - I always find myself doing `GOHACK=$(mktemp -d)`, because more often than not I'm simply poking around...