Open cep21 opened 3 years ago
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.
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.
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.
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.
The command go mod tidy
is working fine without removing anything for me. I wonder if it's a recent go feature.
This workaround fixed the problem of no build if using mage for non go projects.
go get -d -u -tags mage ./...
@cep21 Are you happy with this workaround then? Can we close this issue?
Yes. The only follow up may be to document this somewhere for people using mage for non go stuff. Can close.
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.
This also seems related to #325.
The current accepted convention to solve this is having a file like mentioned above just for build dependencies.
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.
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.
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 thisIf 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 commandgo get -u ./...
It does a pretty good job updating all my dependencies. If I run this wanting to also update mymage.go
file, it does not pick up the file because of the build tag//build +mage
. So I change my update command togo get -u -tags mage ./...
, but now the error isMy 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?