Ability to update go.mod mage dependencies with `go get -u`

[cep21]

Hi,

I have a "mage.go" file at my root. I also have some helper libraries, at a path like github.com/mycompany/magehelpers So my go.mod file may look like this

module github.com/company/project

go 1.16

require (
        github.com/company/magehelper v0.0.18
)

If I push a new version of magehelper, v0.0.19, I would like to update to that version. For most go projects, I do this by running the command go get -u ./... It does a pretty good job updating all my dependencies. If I run this wanting to also update my mage.go file, it does not pick up the file because of the build tag //build +mage. So I change my update command to go get -u -tags mage ./..., but now the error is

< go get -u -tags mage ./...
# github.com/company/project
runtime.main_main·f: function main is undeclared in the main package

My workaround is to use vim to manually change the version in my go.mod file, then run go mod tidy.

Do you know an easy way to update my go.mod dependencies?

[natefinch]

As far as I know, go get should do the right thing, regardless of build tags, because lots of projects use build tags for a lot of different purposes. I'll look into it, but I would be surprised if it didn't work.

[cep21]

I believe the difference is that mage.go is package main, but there is no func main. Because the code isn't valid Go, the go get fails.

[cep21]

Here is a series of console commands

< go get -u -tags mage ./...
# github.com/company/project
runtime.main_main·f: function main is undeclared in the main package

mv /tmp/dummy.go .

< cat dummy.go
// +build useless
package main

func main() {
}

< go get -u -tags mage ./...
go get: upgraded github.com/company/magehelper v0.0.15 => v0.0.30

Rather than keep a dummy.go file in all my repositories, it may be useful for mage to support this as some mage subcommand.

[mirogta]

We had a similar problem. github.com/company/magehelper would be regularly removed with go mod tidy or otherwise, from the company project's go.mod because of the build tags.

We have added a mage.go file to the company project with the import

# mage.go
package main

import _ "github.com/company/magehelper"

... which keeps go happy and allows us to manage this dependency as any other one.

Hope this helps.

[cep21]

The command go mod tidy is working fine without removing anything for me. I wonder if it's a recent go feature.

[cep21]

This workaround fixed the problem of no build if using mage for non go projects.

go get -d -u -tags mage ./...

[mirogta]

@cep21 Are you happy with this workaround then? Can we close this issue?

[cep21]

Yes. The only follow up may be to document this somewhere for people using mage for non go stuff. Can close.

[thaney071]

Easiest way would to reference this from the Golang FAQ wiki: https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

The wiki implies that the suggested "workaround" is actually a valid way in go to manage tools dependencies when using go modules. I am not sure there is another way to update mage with go get -u otherwise.

If I get time over the next month, I can add this to the documentation.

I don't know how well known this is in the Golang community considering the info is only in the wiki FAQ.

[thaney071]

This also seems related to #325.

[sheldonhull]

The current accepted convention to solve this is having a file like mentioned above just for build dependencies.

https://github.com/sheldonhull/magetools/blob/main/starter/root-imports-with-tasks-in-subdirectory/magefiles/build/tools.go

That's an example. I based this on a huge thread discussing this and I've observed it to work well. Just include this type of file in your project for build packages and it won't tidy them away.

[natefinch]

I think this can also be solved once we stop requiring mage files to be in package main. I think that's a thing we can do, at first just with the magefiles directory, and then likely even with interleaved magefiles in the root directory.