Are there any plans of making a "run" command? (As in "gb run"?)

[reiver]

Continuing the conversation from Twitter:

• https://twitter.com/reiver/status/596004239324749824
• https://twitter.com/davecheney/status/596030215924494336

The go command has both go build and go run.

The gb command currently only has gb build but not gb run

Are there any plans of making a run command, as in gb run?

[davecheney]

The short answer is no, I don't plan on adding a gb run subcommand.

The longer answer is: gb is a project based tool, every subcommand works on a list of import paths (packages) within that project, and most default to "all packages in the project".

One of my frustrations with the go tool is its inconsistency in this manner, most go commands work on import paths, like gb, except for go run which takes a file. Actually that's not correct, go run takes a list of files, but your chance of success of using it drops exponentially the more files you pass to go run. (I ranted about this a little at http://dave.cheney.net/2014/01/21/using-go-test-build-and-install)

While I recognise the utility of go run for simple examples, and it's a great way to introduce the language, the fact that it works allowed many new gophers to use it well past the point of its original intent and have a confusing and unsatisfactory time. When they go for help, they have the double wammy that smug experienced gophers tell them "they are holding it wrong" and should learn to restructure their code.

Because gb is focused on a project workflow, not a package or file workflow; most of the time you are building or testing your project (see digression in #49 ) I felt I could make things simpler and more consistent by not supporting gb run at all -- gb commands always take a list of import paths to work on, never a file.

The workaround is, you could write gb run as a plugin, but given what I've said above, it probably won't be as useful as you think.

[reiver]

I'm going off on a bit of a tangent, but thinking about what I (personally) really want from go get is NOT to be able to specify files, but instead to be able to run my program with one command.

So, instead of doing:

gb build
./bin/main

I'd rather do something like:

gb try

(Note I switched run to try in the command above. Better not to reuse that command name if it doesn't do the same thing, so as not to confuse people.)

Seems like a very easy plugin to write.

Although the plugin would have to consider if I'm deep into the {PROJECT}/src directory. (I.e., it might not be as simple as running "./bin/main". Could be "../../../../bin/main".) Or if the compiled binary is named something other than "main". (I.e., could be something like "./bin/apple-banana-cherry".)

[christopherhesse]

To add to davecheney's complaint, there are two issues with go run that I have run into, both causing some debugging time to figure out: 1) the behavior is weird when running as a child process with go run, which means I use go build now to create an executable first then run it, 2) go run seems to rebuild the whole thing every time, so I got a substantial speedup in compile time by using go install

[davecheney]

@reiver the environment gb plugins run in has access to some environment variables set up for it. Well, to be honest, there is just one

lucky(~) % gb env
2015/05/08 11:37:32 INFO project root "/home/dfc"
GB_PROJECT_DIR=/home/dfc

But that should be sufficient for what you need to write gb try, however there are some other considerations.

The first is that gb projects are not limited to a single executable, there can be many. So there is no direct correlation between building and running; building may produce many executables, which one to run ?

I think your workflow is important, and I want to do what I can to make it convenient to use gb, so I'll throw out another suggestion. From the project root, you can build and run with

% gb build && bin/$COMMAND

Maybe that is sufficient

[davecheney]

@christopherhesse

To add to davecheney's complaint, there are two issues with go run that I have run into, both causing some debugging time to figure out: 1) the behavior is weird when running as a child process with go run, which means I use go build now to create an executable first then run it, 2) go run seems to rebuild the whole thing every time, so I got a substantial speedup in compile time by using go install

go run does not cache intermediary results; this is because of the duality between go build and go install. go run is effectively go build -o $TMPFILE && $TMPFILE, so it won't cache any intermediary results.

Explaining the duality between go build and go install has always been frustrating so for gb I made the decision to always cache incremental results, no matter how they are generated (this happens even in tests), removing the requirement to have two different commands.

[christopherhesse]

Yes, I saw that in the docs! I like it.