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= On Fri, Oct 8, 2021 at 10:05 AM Zigster Programmer < zigsterprogram...@gmail.com> wrote: > 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. > > -- > 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+unsubscr...@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 > <https://groups.google.com/d/msgid/golang-nuts/f6224457-a9b8-4920-a1dd-a4197f94eba1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGCADbbz%2BDgPrfG1A9-e-0EfpGs3LKakFD3g_ySOPTCmRsaQQg%40mail.gmail.com.
