Flags for GPM - go binary, the file to parse and disable -u on go get

[markmandel]

Warning: This does break backward compatibility with of specifying the Godep file in $2, but this should be far more flexible in the long run, so I think this is worth it.

There are 3 new options, primarily to make working with GAE much easier.

1) -f The file to parse. Was required, simply because otherwise $2 could be a flag or the file, made things trickier. 2) -g What go binary to use. If you are using GAE, you will want to use the goapp command from your local GAE dev install. 3) -u Be able to manually turn off the -u option on the go get operation. This is just because GAE has libraries in it's GOROOT, and sometimes they conflict. It sucks, but this is a nicer workaround.

Keen to hear feedback, and let me know how I can help test / improve this. It working for me locally in my project.

[markmandel]

Just bumping this.

Happy to take feedback on the pull request if it's not what you are looking for. I need -g and -u 0 things to work with GAE + Go, so for me they are very important, and I expect they would be for other people in similar scenarios.

[pote]

Sorry for taking so long to respond to this PR, I've come back to it several times as I've changed my mind a few times about the patch and am never entirely sure of what to do with it.

The reason being: I dislike gpm having to cater to a specific developing environment doing things that are not really required by Go itself, still: it's Google App Engine, so ideally I'd like gpm to be able to play along with it, so maybe we can find a way.

The approach does not fully convince me: I dislike getopts because of the verbosity of code and command line interface it adds. How do you feel about attacking this from a slightly different angle by using ENV variables? Maybe we could have two variables determining:

1) The Go executable to be used (can GOROOT be used for this? It seems to me like it could, a different variable if not) 2) The go get flags to use, defaulting to -u -d.

This would mean that gpm would gain the flexibility to work with GAE (and other tools, probably, if it plays along with GOROOT) as well as a fair bit more customisation of behaviour (some users have expressed that it'd be nice to actually install the packages too by removing -d from go get, they'd be able to do that now). All these improvements would come without gpm having to be aware of whatever Go version is being used or a lot of complex CLI parsing logic.

What do you think?

[markmandel]

I'm coming back to this slow now as well ;) Basically because my forked version of GPM has been working for us so well.

I don't think you can use GOROOT, simply because the name of the binary is actually different. goapp vs go

So in theory gpm would have 2 new Environment variables that it would look at GOBIN - which would be the go binary to use. GETFLAGS - which would be the Flags to pass to go get?

This could work. Devil's advocate would state that it seems totally different from every other command line tool out there that generally uses some kind of argument/flag on the binary, rather than environment variables.

Maybe I could implement better flags? i.e. --go-binary=/path/to/goapp rather than just -g ? and --go-get-options="-d" ? Would that be nicer?

[pote]

While I still think there is merit to the ideas here this pull request is too far removed from the current master for it to be merged.

I'm closing it based on that, but anyone reading can feel free to open an issue with the issues here.

Thanks for the contribution!