Open owenwaller opened 2 months ago
I think if you make the magefiles directory into its own go module (by running go mod init github.com/vugu/vugu/magefiles
in that directory) then its dependencies won't creep into the main project's dependencies. And I don't think it'll change mage's behavior. I haven't tried it, but I think that should work.
Report back how it goes or ping me on the #mage channel on the gophers slack. I'd like to know if you can get it working, so we can make it a recommendation for people who want to keep the dependencies of their main project clean (which I totally understand).
@natefinch
Many thanks for the suggestion. I've just tried it and it does indeed work. Brilliant.
The critical part is to execute both go mod init
inside the magefiles
directory but also any go get ...
commands to add any mage
only dependencies inside the magefiles
directory.
After that a simple mage ...
will work.
Can we add this tip into the mage
documentation? If you know where you would want this, I am happy to create a PR based on the above example.
By way of an example, following on from my original question.
$ cd magefiles # so from within the magefiles directory
$ go mod init example.com/mage_build/magefiles
$ go get github.com/magefile/mage/sh
$cat go.mod
module example.com/mage_build/magefiles
go 1.22.1
require github.com/magefile/mage v1.15.0 // indirect
$cd .. # to get back put of the magefiles directory
$cat go.mod # to check the project level go.mod is untouched
module example.com/mage_build
go 1.22.1
# now build as normal
$mage build
Mage Hello # this is the expected output given the magefile above
$mage_build # run the executable given the main.go above
Hello World
Bug Description
Adding the
github.com/magefile/mage/sh
package into amagefile
causesgithub.com/magefile/mage v1.15.0
to be added as an indirect dependency in the projectsgo.mod
.But
github.com/magefile/mage/sh
is only required by themagefile
itself. It's got nothing to do with, and will never be called by (either directly or indirectly) the project code itself.Is there a way to give a
mage
based build it's owngo.mod
for just themagefile
imports?The
mage.go
magefile we are using is in a localmagefiles
directory.What did you do?
Hopefully these shell lines should be sufficient to reproduce the issue.
What did you expect to happen?
The project's
go.mod
should be untouched. Ifmage
needs ago.mod
file then it should generate/update a private one (used only for themage
build) and not any project levelgo.mod
.Just to be clear I mean the projects (or project level)
go.mod
file to be the one at the root of the projects repository. So what Go would take as the module root IIRC.What actually happened?
The project level
go,mod
was updated with an indirect dependency that will never be called directly or indirectly by the project itself.Environment
Additional context
A bit of background information....
Over at the vugu project we have been trying to update the build process for both maintainers and contributors, with a view to:
wasm-test-suite
tests that the project uses. Currently this involves two docker containers that have to be networked together, such that a locally running go test connects to one container (which has a chrome headless browser running in it) that then in turn connects to the second container (running nginx) that is serving thewasm
object. We need to pass the generatedwasm
though a browser to see if the effect of thewasm
is what we expect after the browser has executed it. We can't use awasm
runtime because the generated code will call the browsers DOM manipulation JS API's. Thewasm
code is never intended to run on a server via a JS runtime,We've experimented with using Taskfile but basically run into a dead end with it. it's just to difficult to get to to loop over results from a command and writing shell in a YAML with added Go templates which is pretty painful experience.
We can't go for a simple shell script because we need this to be cross platform. Ditto a Makefile.
mage
looks like it might be a very good fit for us as any small parts we need to be cross platform (e..g. removing all the generated files under a directory tree) we can easily rewrite in Go. But, still benefit formage
task dependency and better shell integration etc. It also looks like less code for us.But at the minute we are seeing dependencies being inserted into the
vugu
projectsgo.mod
file thatvugu
itself or and of thevugu
commands (vugugen
vugufmt`) will never ever call (directly or indirectly).We'd really like to keep the Magefile(s) in the
magefiles
directory, so thevugu
code and the build scrips are all in the same repo.Is this just something we have to live with, or can this be fixed?
Thanks