Address some TODOs

[krnowak]

So far three of them are addressed - about specifying arguments to exec, about setting custom GOPATH and about doing static builds for go-1.4.

This also addresses #1 - GOROOT and GOPATH env vars are ignored.

The third one is problematic from distro point of view - if using go provided by distro (Fedora 21 in my case), then goaci can fail with following message: go install runtime: mkdir /usr/lib/golang/pkg/linux_amd64_netgo/: permission denied

Not sure if there's a way to specify different pkg directory where libs could be stored. GOPKG env var would be cool (like GOBIN). Specifying installsuffix to something like /tmp/goaci-XXXXXX/netgo resulted in: go install runtime: mkdir /usr/lib/golang/pkg/linuxamd64: permission denied

I suppose running goaci for the first time as root might "fix" it, but it's messy - I haven't tried that.

In the meantime I fixed the "go get" command invocation - the package name (github.com/coreos/etcd) wasn't passed there, so go get was actually getting the package from current working directory.

Next step could be addressing the "// TODO(jonboulle): support multiple executables?", but the code now needs refactoring. Currently, almost everything is just in main function.

[jonboulle]

@krnowak thanks for tackling this!

I am a bit ambivalent about adding flags or having things configurable through environment variables. My original idea was to try keep it as flag-compatible as possible with go get (so basically we would just pass on os.Arg[1:] unadulterated to the go get invocation, and configure goaci itself through env vars). But maybe that's not practical/sustainable as the set of things configurable for goaci expands. Thoughts?

[krnowak]

I don't think it's practical - we are a separate tool, we don't have to mimick any go tool. That allows us to change parameters we pass to go get to keep static linking working for example without worrying that we broke some workflow (and if we broke, it's go's fault :) ). Basically, we can say that go get it's an implementation detail. We might still implement something like --go-get-flags, but yuck.

Otherwise the parameters we pass to go get ought to be documented and we probably should promise that this won't change, or somebody will complain that we just broke his workflow. ;) Also, at this point go get stops being an implementation detail.

Oh, and so far goaci was rather backwards to your original idea - configuring go get with env vars and configuring goaci with flags (as TODO said for adding parameters to ACI exec). :)

[jonboulle]

I don't think it's practical - we are a separate tool, we don't have to mimick any go tool. ....

Yeah, I'm convinced.

Please fix the GOROOT thing, then this is good to merge! Thanks!