Open
Description
I'm trying to use migrate in conjuction with the new go tool
command (https://tip.golang.org/doc/go1.24#go-command), but not having much luck. I wondered if anyone knows knows a workaround or the right commands to run?
I've tried:
$ go get -tool github.com/golang-migrate/migrate/v4/cmd/migrate@latest
$ go tool migrate -path ./migrations -database postgres://user:pa55word@localhost/db_name up
But this fails with the following error.
error: failed to open database: database driver: unknown driver postgres (forgotten import?)
I tried specifying the build tag postgres
during the go get
, but get the same error.
$ go get -tool -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest
$ go tool migrate -path ./migrations -database postgres://user:pa55word@localhost/db_name up
error: failed to open database: database driver: unknown driver postgres (forgotten import?)
In contrast, go run
with the build tag postgres
works as expected:
$ go run -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest -path ./migrations -database postgres://user:pa55word@localhost/db_name
up
no change
Metadata
Metadata
Assignees
Labels
No labels
Activity
eberkund commentedon Mar 4, 2025
It would be nice to be able to manage all my tool dependencies using the same method.
I guess the problem is that
go get -tool
does not support tags. Maybe migrate could include all the drivers by default and have another tag to exclude drivers?bcomnes commentedon Mar 21, 2025
fwiw, when you use
go run -tags 'postgres'
, you can have migrate defined in your tool sections and it will use that version. Stashing this in a makefile seems to be a decent solution.skandragon commentedon Mar 23, 2025
I'm not sure this is true...
I have it added to my go.mod:
However:
bcomnes commentedon Mar 23, 2025
With the following makefile commands:
Without migrate in my tools directive I get:
With migrate in my tools directive, I get:
I don't have a firm grasp on the nuances of the tool directive, so if this is working in some kind of unexpected way, maybe someone can clarify.
Example repo: https://github.com/bcomnes/go-todo
skandragon commentedon Apr 1, 2025
@bcomnes I think what you describe is a side-effect.
When you have no tools included, do you still have a reference to
github.com/golang-migrate/migrate/v4/cmd/migrate
or the package it is included in within yourgo.mod
?My guess here is the tool definition is creating it, but since you are explicitly running it based on the
go run
and notgo tool
command, it is taking what it sees inside your mod file and running that, and that can use the tags.bcomnes commentedon Apr 10, 2025
No, nothing else pulls it in when the tools directive is removed.
It's not quite the desired outcome (using
go tool
) but it is close (defining the dep and version as a tool, and running it at the correct version, controlled by the mod file, afaict).yshngg commentedon Apr 11, 2025
I propose adding a new file
internal/cli/build.go
with the following build constraints to control database/source driver imports:This setup ensures that all database/source drivers are built by default when running go build without any
-tags
flags. The build constraints work as follows://go:build
directive (Go 1.17+ syntax) uses negation to exclude specific drivers// +build
format maintains compatibility with older Go versionsFurther validation needed.
dhui commentedon Apr 17, 2025
Thanks for the discussion! I'd rather wait for
go tool
to support build tags and not complicate our builds/codebase. Currently, build tags are all managed in theMakefile
and I don't want another place to update when adding a new db or source driver.yshngg commentedon Apr 18, 2025
Hi @dhui , thx for the response! 🙏 The existing Go community issue golang/go#71503 hasn't seen progress yet. Hoping to provide a temporary workaround here so other projects can manage tool dependencies in
go.mod
via go tool.