mage icon indicating copy to clipboard operation
mage copied to clipboard

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

Open cep21 opened this issue 4 years ago • 12 comments

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?

cep21 avatar Apr 21 '21 00:04 cep21

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.

natefinch avatar Apr 21 '21 01:04 natefinch

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 avatar Apr 21 '21 04:04 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.

cep21 avatar Apr 21 '21 04:04 cep21

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.

mirogta avatar Apr 21 '21 08:04 mirogta

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

cep21 avatar Apr 21 '21 17:04 cep21

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

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

cep21 avatar Jul 21 '21 20:07 cep21

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

mirogta avatar Sep 24 '21 13:09 mirogta

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

cep21 avatar Sep 24 '21 15:09 cep21

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 avatar Nov 25 '21 05:11 thaney071

This also seems related to #325.

thaney071 avatar Nov 25 '21 06:11 thaney071

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.

sheldonhull avatar Apr 26 '22 15:04 sheldonhull

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.

natefinch avatar Apr 26 '22 19:04 natefinch