GoImports version

[shan...@gmail.com]

Hi all,

I have a need to (programatically) check what version of `goimports` someone has installed on their system.

I cannot, for the life of me, figure out if there's a way to do it other than

https://groups.google.com/g/golang-nuts/c/in9IVmPc_fQ/m/O4vYNNAZCQAJto golang-nuts

hey brad, is it possible to have a ```goimports version``` so that we know what versions we currently have?

I suggest using the command:go get -u -v golang.org/x/tools/cmd/goimportsThe -v flag will print packages that are rebuilt. If the output is empty, that means you already had the latest version. If the output is not empty, that means you had an outdated version, but now it's up to date.If you want to find out whether your version is up to date before actually updating it, you can use gostatus and binstale tools.

[Axel Wagner]

You can look at `go version -m /path/to/goimports` to get the version of the golang.org/x/tools module.

I seem to remember that there was a way to get that information out of a binary programatically as well, but I can't find it right now. You might try to look at what the `go version` command does, as a starting point. It's also the same that debug.ReadBuildInfo returns, so that might be a good starting point as well.

I'll also note that many if not most Go users these days probably use gopls rather than goimports.

--
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/811798e7-2a10-460b-892d-f214aefdeaf2n%40googlegroups.com.

[shan...@gmail.com]

Awesome, I think that that will work for us

FTR, I hadn't realised that `gopls` usurped `goimports` - I shall be updating my ~/.vimrc forthwith :)

[Kurtis Rader]

On Thu, Oct 17, 2024 at 10:31 PM shan...@gmail.com <shan...@gmail.com> wrote:

I have a need to (programatically) check what version of `goimports` someone has installed on their system.

It might help if you told us why you need to do that.

The answer by Axel Wagner is somewhat helpful but the output of "go version -m ..." is meant for human consumption and hard to reliably parse by a program. On my system (where I haven't performed any updates in several months):

> go version -m /opt/bin/goimports

/opt/bin/goimports: go1.23.0

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

mod golang.org/x/tools v0.24.0 h1:J1shsA93PJUEVaUSaay7UXAyE8aimq3GW0pjlolpa24=

dep golang.org/x/mod v0.20.0 h1:utOm6MM3R3dnawAiJgn0y+xvuYRsm1RKM/4giyfDgV0=

dep golang.org/x/sync v0.8.0 h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=

build -buildmode=exe

build -compiler=gc

build DefaultGODEBUG=asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,panicnil=1,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1

build CGO_ENABLED=1

build CGO_CFLAGS=

build CGO_CPPFLAGS=

build CGO_CXXFLAGS=

build CGO_LDFLAGS=

build GOARCH=arm64

build GOOS=darwin

build GOARM64=v8.0

Apparently my current version of goimports is v0.24.0. After updating my Go related CLI tools (via "go install golang.org/x/tools/...@latest") running "go version -m /opt/bin/goimports" reports

/opt/bin/goimports: go1.23.0

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

mod golang.org/x/tools v0.26.0 h1:v/60pFQmzmT9ExmjDv2gGIfi3OqfKoEP6I5+umXlbnQ=

...

It's not obvious to me how to reliably extract the relevant version from the "go version -m" output for a specific CLI tool. Should there be a reliable way to programmatically do so? I'm inclined to answer "yes" but it's not obvious that should be done by something like "go version -m ..." or something like "/path/to/command -json -version". Obviously all of the approaches discussed involve running an external command and parsing its output. Which has its own set of problems regardless of the output produced by that command. And, obviously, how do you handle a command named "goimports" installed by the user that is not from the golang.org/x/tools repository.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Axel Wagner]

I tried it out and the format parsed by debug.ParseBuildInfo is almost exactly what is output by go version -m:

https://go.dev/play/p/L-MNzr0EnjV

(and yes, my goimports version is old)

--

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/CABx2%3DD-uBkK%2B%2B8BSvdxxmYOQFxvGo5N%3D5qzKnvtHh0XwMqyiww%40mail.gmail.com.

[Axel Wagner]

On Fri, 18 Oct 2024 at 08:20, Kurtis Rader <kra...@skepticism.us> wrote:

And, obviously, how do you handle a command named "goimports" installed by the user that is not from the golang.org/x/tools repository.

I'll note that it should be trivial to check if the BuildInfo.Main.Path is golang.org/x/tools and BuildInfo.Path is golang.org/x/tools/cmd/goimports. Obviously, it's possible that a user has a carefully crafted binary that contains lying build information in the corresponding ELF sections. But let's not have the perfect be the enemy of the good enough.

[Axel Wagner]

Damn, I keep forgetting that I had other stuff to say:

My main concern with this approach is that the BuildInfo embedded into binaries is incomplete in a bunch of circumstances - for example, if you clone the repository and run `go build` in it (I believe) or if someone uses a `goimports` version with local modifications that otherwise behaves like some upstream version.

It's *probably* fine and even intended for the version information to be missing and considered incompatible in those cases, but it's a caveat I found when trying to use BuildInfo in practice.

[Jan Mercl]

On Fri, Oct 18, 2024 at 9:17 AM 'Axel Wagner' via golang-nuts
<golan...@googlegroups.com> wrote:

> I tried it out and the format parsed by debug.ParseBuildInfo is almost exactly what is output by go version -m:
> https://go.dev/play/p/L-MNzr0EnjV
> (and yes, my goimports version is old)

And https://go.dev/play/p/bgeGr2hVCsb

[Axel Wagner]

On Fri, 18 Oct 2024 at 09:16, Axel Wagner <axel.wa...@googlemail.com> wrote:

I tried it out and the format parsed by debug.ParseBuildInfo is almost exactly what is output by go version -m:

https://go.dev/play/p/L-MNzr0EnjV

(and yes, my goimports version is old)

*sigh* realized that version had a bug that silently dropped the package path. https://go.dev/play/p/O9E6sVyEnpH is simpler and works.