fix: generated wire file to be compatible with workspaces

[jhamill34]

Fixes #403

Problem

After trying to run wire ./... on a module inside of a go workspace subsequent calls to go generate ./... fail

go: -mod may only be set to readonly or vendor when in workspace mode, but it is set to "mod"
        Remove the -mod flag to use the default readonly value,
        or set GOWORK=off to disable workspace mode.
internal/app/wire_gen.go:3: running "go": exit status 1

This is because the wire_gen.go files contain the following generate command (see #403 for more details)

// go:generate go run -mod=mod github.com/google/wire/cmd/wire

Solution

This fix adds a flag to the compiled binary to allow this flag to be either unset or overridden with a different value.

For example running this command:

wire gen -mod=readonly ./...

Would generate the following wire_gen.go file

// Code generated byWire. DO NOT EDIT.

//go:generate go run -mod=readonly github.com/google/wire/cmd/wire
//go:build !wireinject

// .. rest of the code ..

Calling wire gen -mod=unset ./... would remove the flag in the generated file all together and calling without the flag (i.e. wire gen ./...) will default to the current behavior of setting -mod=mod.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jhamill34]

I'm realizing that this fix works until you run go generate ./... and then the issue comes back because the added flag needs to be present in the generate command in the file's header. So for this solution to work it'll need to play nice with the existing -tag flag.

For example:

// go:generate go run github.com/google/wire gen -mod=readonly

[euskadi31]

Hello, do you have any news regarding the progress of this PR?

[jhamill34]

@euskadi31 Unfortunately I don't think this project is actively maintained anymore, the README claims its been feature complete. The last release was almost a year ago and to support Go 1.22 and before that the last commit was in 2022.

At this point, Its unlikely the maintainers merge this PR.

[euskadi31]

@euskadi31 Unfortunately I don't think this project is actively maintained anymore, the README claims its been feature complete. The last release was almost a year ago and to support Go 1.22 and before that the last commit was in 2022.

At this point, Its unlikely the maintainers merge this PR.

I understand, but here, it is not a new feature, but more a bug with the functioning of the go workspaces...

In any case, thanks for this PR, I found a workaround using sed... after the go generate

[jhamill34]

Fair, I suppose we could get input from the maintainers.

@zombiezen and @vangent what's your take on this issue? I understand this repo is feature complete, but would you consider this a bug fix that would be worth adding to the next release?

[zombiezen]

I'd be up for reviewing a fix for something like this; it seems important. In general, the amount of time that I have for back-and-forth code reviews on this project is pretty limited.

Glancing over the description and the issue, my main question is: do we need to introduce a new flag for this? Wire was built when Go modules were fairly new, so I suspect the -mod=mod construct was more a hack to force some non-default behavior at the time. The go tool has matured enough that I think go run without options would be fine, I think? LMK if I'm off-base.

[ralf-cestusio]

I can remember this from a time before wire was calling -mod=mod.
It was because of a "user error"
in a project which is using wire. Wire is not included. So go mod tidy removes it from the go.sum which then created an error.
setting -mod=mod allowed wire to modify that behavior (which is arguably bad :) )

The workaround was to have a tools.go with something like

// +build tools

// following https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

package main

import (
	_ "github.com/google/wire/cmd/wire"
)

But there is now/will be (golang 1.24) a tool directive in go.mod

https://go.dev/ref/mod#go-mod-file-tool