proposal: refactor to be used as a library

[japettyjohn]

I've been working over my own local development processes (which is itself written in go) and have taken to using gobin (because it's awesome) as part of that solution. Currently I'm calling that from os.exec - but it would be far more versatile as a library.

[myitcv]

My immediate response would be "no" simply because we've all managed to live with the go command not being a library! It just feels like we'd be creating another API surface we'd have to maintain, which given gobin largely calls out to the go command doesn't seem worth the effort.

Can you give a few more details?

cc @rogpeppe @mvdan

[japettyjohn]

In my scenario I have a mix of local code to go run/go build + exec and with non-local code being run with gobin -run. I would be extending the work of gobin but a good deal of the logic is buried in the main function and a smattering of it in unexported functions. I'm not arguing in any degree that it works - I am using it and I'm glad I'm not having to write everything. Unfortunately this means instead of using a slightly less opaque API of functions, I'm having to write another similar layer, which is not very maintainable and difficult to maintain.

Another aspect of it is going from what binary it's using to where the source files are, which unfortunately for some projects I need access to.

I've also had to use the go APIs for parsing go.mod data which at least exists talks are going that they may be putting that in the standard lib.