How to automatically embed module name from go.mod into executables?

[Zigster Programmer]

One of my pet peeves with all executables, not just those created with go, is that determining their origin can easily be lost in the mists of time.

This is a problem because I might "go get" some source code and install it, then not update it for many years. Then when I have some need to do the update, I have completely lost track of where the code came from and I might have long ago blown away my ~/go src directory.

Then I have to do a bunch of web searches and run strings/grep on the executable in the hope that some URL will be exposed. Most often tho I fail.

For example, consider the 'q' command in  https://github.com/miekg/exdns/blob/master/q/q.go. 'q' is a fantastic utility that I've used for years yet it takes me ages to re-discover the origin and do an update because the 'q' executable gives no clue as to where it came from. It's also an awful term to use when you make a web search.

Sorry for the long-winded prelude.

What I'm leading up to is this, is there a way of automatically importing the module name from the go.mod file into all go generated executables such that we can automatically discover the origin URL without authors needing to write any code?

If not, how do we make it so?

The obvious wrong answer is to use the "embed" package.

It's the wrong answer because embed doesn't allow you to look above the current directory, so if you have github.com/me/somepackage/cmd/somecommand then somecommand cannot embed ../../go.mod

For those of you who have been around Unix for a while, what I effectively want to replicate is the "ident" command for go executables. Ideally all that such executables need to do is import an "ident" package and they get it for free.

I think go is uniquely place because of the existence of go.mod. IOWs, it should be a no-brainer to get the module path embedded into the executable, but for the life of me I cannot work out how such an "ident" package can do that.

So I need help.

[Jay Conrod]

Good news! The main package path, the containing module, and all of the dependencies and their versions are already embedded in Go executables. You can read that info with `go version -m path/to/exe`.

$ go install golang.org/x/tools/cmd/stringer@latest

$ go version -m ~/go/bin/stringer

/Users/jayconrod/go/bin/stringer: go1.17.2

path golang.org/x/tools/cmd/stringer

mod golang.org/x/tools v0.1.7 h1:6j8CgantCy3yc8JGBqkDLMKWqZ0RDU2g1HVgacojGWQ=

dep golang.org/x/mod v0.4.2 h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=

dep golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e h1:WUoyKPm6nCo1BnNUvPGnFG3T5DUVem42yDJZZ4CNxMA=

dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f6224457-a9b8-4920-a1dd-a4197f94eba1n%40googlegroups.com.

[Christian Stewart]

Is there a way to /not/ have this information in the binary?

[Dan Kortschak]

On Fri, 2021-10-08 at 16:36 -0700, Christian Stewart wrote:
> Is there a way to /not/ have this information in the binary?
>

You can use the garble tool[1] to strip/garble things like this.

$ cd golang.org/x/tools/cmd/stringer
$ garble build .
$ go version -m stringer
stringer: unknown


[1]https://github.com/burrowers/garble

[Zigster Programmer]

Huh. I did not realise that. Thanks very much, Jay.