code review 12869048: cmd/go: add 'oracle' to list of tools.

cmd/go: add 'oracle' to list of tools.

(Oracle itself is in CL 9502043.)

[adonovan, 2013-08-22 17:58:33]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[adonovan, 2013-08-22 17:59:09]

Hello r@golang.org, gri@golang.org (cc: golang-dev@googlegroups.com),

Please take another look.

[r, 2013-08-22 21:54:03]

What is the oracle? What does it do? It's not even checked in yet.

[adonovan, 2013-08-22 22:29:55]

On 22 August 2013 17:53, Rob Pike <r@golang.org> wrote:

> What is the oracle? What does it do? It's not even checked in yet.
>

Its code is in pending CL 9502043, currently in review.  It is an oracle
that answers questions about your Go program: given a source code position
(e.g. an expression selected in your editor buffer) and a query (e.g.
"describe") it will analyze your program and print the answer, often in the
form of cross-references to other parts of the program.  The user's editor
(currently Emacs, others to follow) invokes it via "go tool oracle".

I haven't written a manual for it yet but obviously that's high on my list.
 I would like to get some feedback from early adopters soon.

[adg, 2013-08-23 00:09:26]

Since this isn't really a command-line tool I'm not sure it's worth making
it accessible through the go tool.

I'd prefer to keep the number of special-cased tools to a minimum. vet,
godoc, and cover are special for various reasons.

[r, 2013-08-23 00:22:14]

I tend to agree. It may move to 'tool' status at some point but we
need to see it in action, and have it more generally useful (that is,
not just an emacs plugin), before making that decision.

For the record: All it takes for a local installation to have 'go tool
oracle' work is to copy the binary to the tool directory. The 'go
tool' command is just a shorthand for running a binary from that
directory.

That solution seems workable and sufficiently non-committal for the moment.

-rob

[adonovan, 2013-08-26 18:51:03]

*** Abandoned ***

[adonovan, 2013-08-26 21:18:28]

adg wrote:
> Since this isn't really a command-line tool I'm not sure it's worth
making it accessible through the go tool.

On 22 August 2013 20:21, Rob Pike <r@golang.org> wrote:

> I tend to agree. It may move to 'tool' status at some point but we
> need to see it in action, and have it more generally useful (that is,
> not just an emacs plugin), before making that decision.
>
> For the record: All it takes for a local installation to have 'go tool
> oracle' work is to copy the binary to the tool directory. The 'go
> tool' command is just a shorthand for running a binary from that
> directory.
>
> That solution seems workable and sufficiently non-committal for the moment.
>

I've reverted this CL for now, but I should point out that the alternative
is significantly more fiddly.  Even though the user is not expected to run
the oracle tool directly, the benefit of being a 'go tool' subcommand is
that both installation and invocation of the oracle have one and only one
configuration requirement: that there be a command called 'go'.  (In my
setup, for example, 'go' is a wrapper that selects the appropriate GOROOT
and GOPATH---each of which I have several---based on the working directory,
then dispatches to the real 'go' tool binary.)

So expect this CL to reappear when the oracle is more mature. :)