Build all Database and Source drivers by default

[yshngg]

Support the new Go 1.24 feature: using go tool to track tool dependencies.

Current:

$ go tool github.com/golang-migrate/migrate/v4/cmd/migrate
Usage: migrate OPTIONS COMMAND [arg...]
       migrate [ -version | -help ]
...
Source drivers: file
Database drivers: stub

Expected:

$ go tool github.com/golang-migrate/migrate/v4/cmd/migrate
Usage: migrate OPTIONS COMMAND [arg...]
       migrate [ -version | -help ]
...
Source drivers: go-bindata, github-ee, gitlab, bitbucket, s3, gcs, file, github, godoc-vfs
Database drivers: cockroach, redshift, cockroachdb, yugabytedb, firebird, firebirdsql, mysql, cassandra, rqlite, spanner, mongodb, snowflake, stub, postgresql, yugabyte, clickhouse, sqlite, ysql, neo4j, sqlserver, mongodb+srv, ql, sqlcipher, sqlite3, pgx, postgres, pgx5, crdb-postgres, pgx4
exit status 2

Go 1.24 Release Notes

Fix #1232

[coveralls]

coverage: 56.319%. remained the same
when pulling b410679 on yshngg:feature/build-constraints
into 604248c on golang-migrate:master.

[dhui]

See #1232 (comment)

[dhui]

I'm curious why this was needed

[yshngg]

Copied from build_clickhouse.go.

migrate/internal/cli/build_clickhouse.go

Lines 5 to 8 in 9023d66

	import (
	_ "github.com/ClickHouse/clickhouse-go"
	_ "github.com/golang-migrate/migrate/v4/database/clickhouse"
	)

[abh]

Building all drivers by default seems unfortunate, in particular in a workflow where everyone is compiling it (as happens with go tool).

A simpler path might be moving /cli/ out of /internal to make it easier for a project to have their own main function that otherwise just imports everything in the cli?

[yshngg]

Hi @abh ! Nice suggestion!

One potential issue: This approach currently lacks multi-driver support. For example, projects needing both PostgreSQL + MongoDB would hit limitations.

[abh]

@yshngg how so?

I tried it in one of my projects by just copying main.go, log.go and commands.go into a new package (foo/bar/cli) and then I could make a custom main package (see below) that I then use in my tools section.

If the cli package wasn't in internal/ I could just import the existing code and my "custom program" would just be the lines below.

Ask

package main

import (
	"github.com/foo/bar/cli"
	_ "github.com/golang-migrate/migrate/v4/database/pgx/v5"
	_ "github.com/golang-migrate/migrate/v4/database/clickhouse"
)

func main() {
	cli.Main(Version)
}

[yshngg]

@yshngg how so?

If the cli package wasn't in internal/ I could just import the existing code and my "custom program" would just be the lines below.

@abh apologies for the earlier misunderstanding! 🙏 Your idea is indeed viable, but I'm concerned it might add unnecessary complexity to our workflow with golang-migrate/migrate.

@dhui , any thoughts?