cmd/fyne: command ”get” is broken with Go 1.22

[Guddler]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

Generally my Golang installation is working OK. I have previously used an old version of Fyne (1.x) and I don't recall any issues. I'm now trying to install fyne_settings with the command fyne get github.com/fyne-io/fyne/cmd/fyne_settings and I can't get past the dreaded error "go: modules disabled by GO111MODULE=off" when in fact, that is not the case.

Here is the output:

fyne get github.com/fyne-io/fyne/cmd/fyne_settings
go: modules disabled by GO111MODULE=off; see 'go help modules'
exit status 1

go env | grep GO111MODULE
GO111MODULE='auto'

echo $GO111MODULE

 

How to reproduce

1. From command prompt enter fyne get github.com/fyne-io/fyne/cmd/fyne_settings
2. Observe that it probably worsks for you.
3. It doesn't for me!

Screenshots

No response

Example code

Code is not relevant to this issue

Fyne version

v2.4.4

Go compiler version

1.22.0

Operating system and version

macOS Monterey

Additional Information

Clearly, given nobody else seems to be reporting this problem, this is highly likely a 'me' problem but I'm not sure where to start.

[andydotxyz]

Hmm, this is weird.
Do you get the same if you try "go install" instead of "fyne get"?

[Jacalz]

I think Go 1.22 is unsupported by fyne get. Didn't they remove the support for GO111MODULE=off?

[Jacalz]

"go get is no longer supported outside of a module in the legacy GOPATH mode (that is, with GO111MODULE=off). Other build commands, such as go build and go test, will continue to work indefinitely for legacy GOPATH programs. " from https://tip.golang.org/doc/go1.22. I think we need to patch cmd/fyne for the v2.4.5 release (and backport to the tools repo).

[Guddler]

Thanks for the reply. I get this:

go install github.com/fyne-io/fyne/cmd/fyne_settings@latest
go: github.com/fyne-io/fyne/cmd/fyne_settings@latest (in github.com/fyne-io/[email protected]):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

At this point I'm questioning if my Go install is still sane. I would clear it out and start fresh but I have to be careful as I have a small proxy application to support in production. I'm basically trying to review UI frameworks and find one for some simple desktop tools.

[Jacalz]

You are missing a v2 in the import path: Try go install github.com/fyne-io/fyne/v2/cmd/fyne_settings@latest :)

[Guddler]

go install github.com/fyne-io/fyne/v2/cmd/fyne_settings@latest
go: downloading github.com/fyne-io/fyne/v2 v2.4.4
go: github.com/fyne-io/fyne/v2/cmd/fyne_settings@latest: version constraints conflict:
        github.com/fyne-io/fyne/[email protected]: parsing go.mod:
        module declares its path as: fyne.io/fyne/v2
                but was required as: github.com/fyne-io/fyne/v2

That does feel like an improvement.

@Jacalz are we saying that the Fyne command line tool is essentially ignoring what is configured for GO111MODULE and setting it to off regardless? That would certainly make sense and explain why I couldn't understand what was going on.

[Jacalz]

Sorry. My fault for giving you the wrong path. Try go install fyne.io/fyne/v2/cmd/fyne_settings@latest instead. You should never try to import using github.com for our project. It is the wrong import path.

[Guddler]

@Jacalz Thank you - that works. I did try changing the URL but still had github in there.

To be clear, for my current purposes, I don't NEED this and am now fine to progress with evaluation. But if there is an actual issue here then please leave it open. Otherwise, I'm happy to close since using go install get's me past the hurdle I was having.

[Jacalz]

@Jacalz are we saying that the Fyne command line tool is essentially ignoring what is configured for GO111MODULE and setting it to off regardless? That would certainly make sense and explain why I couldn't understand what was going on.

Yes and no. It is forcing it to off because it made sense earlier versions when go get would add the packages to your go.mod file if you installed a package from within a Go module folder. Go versions have since removed the support for installing binaries using go get for that reason. The fix is to update

fyne/cmd/fyne/internal/commands/get.go

Lines 60 to 61 in e332a5e

	cmd := execabs.Command("go", "get", "-u", "-d", pkg)
	cmd.Env = append(os.Environ(), "GO111MODULE=off") // cache the downloaded code

to remove the environment variable and use go install with @latest at the end :)

[Jacalz]

There is a genuine bug here. Lack of support for Go 1.22 to be specific. Let's get a fix into the next bug fix release :)

[Jacalz]

You are more than welcome to reach out if you find more problems or just need help. The Gophers slack at #fyne is where we usually hang out.

[Guddler]

Thank you!

[andydotxyz]

@Jacalz are we saying that the Fyne command line tool is essentially ignoring what is configured for GO111MODULE and setting it to off regardless? That would certainly make sense and explain why I couldn't understand what was going on.

Yes and no. It is forcing it to off because it made sense earlier versions when go get would add the packages to your go.mod file if you installed a package from within a Go module folder. Go versions have since removed the support for installing binaries using go get for that reason. The fix is to update

fyne/cmd/fyne/internal/commands/get.go

Lines 60 to 61 in e332a5e

	cmd := execabs.Command("go", "get", "-u", "-d", pkg)
	cmd.Env = append(os.Environ(), "GO111MODULE=off") // cache the downloaded code

to remove the environment variable and use go install with @latest at the end :)

The summary is great, but the conclusion over simplifies.
So as a note to anyone who comes in to solve this - the "go get with modules off" is required because it's side-effect is downloading the source code to a known location so we can then package it. If we just delegate to "go install" it won't build and install the graphical version.
So it may be that "git clone" plus "go mod tidy" may be the replacement for "go get" in this case...

[Jacalz]

Right. Good point. That is indeed problematic.