Default use of "package main" in Go migrations doesn't play nice with go get

[Edward Robinson]

Hi,

We're beginning to use goose to manage migrations in our DBs. Seems great so far — many thanks!

One issue though: we use go get ./... when deploying / testing to ensure that we have all the dependencies to run the project. Becuase goose uses package main for the migrations we are forced to add Main functions in each of the migration directories.

By default, if we don't add the Main functions, when we run go get ./... in our project we get errors along the lines of:

$ go get ./...
# github.com/org/project/warehouse
runtime.main: undefined: main.main
# github.com/org/project/db/migrations
runtime.main: undefined: main.main
# github.com/org/project/warehouse/migrations
runtime.main: undefined: main.main

We have a db dir with dbconf.yml and migrations dir for one db and similar for our warehouse under the warehouse dir.

I tried changing the package from main to something else in the migrations, but then I have trouble running the actual migrations using goose.

Any ideas here?

[Liam Staskawicz]

Hm, that is a bit annoying.

Currently, migrations use package main since they ultimately get executed via go run which, when running multiple source files, requires package main to be used.

One solution here may be that we need to be a little more sophisticated in how we build & execute the migration executable, shelling out to go build directly.

Maybe there's another solution that involves telling the go tool not to try to build these folders by default, though I'm not aware of a good way to do that off the top of my head.

Will update here with a proposal when I get a chance.

[Liam Staskawicz]

One quick thought - can you use the -d flag to go get in order to only download the packages, without installing them? This is not quite as convenient, but could be pretty simple in the short term.

[Edward Robinson]

I'll try that and see how if it works for us (I think it will).

[Liam Staskawicz]

@edwardr - not sure if this is still on your radar. mind if I close out this issue?

[Liam Staskawicz]

Resolving for now, due to lack of response from OP. Please re-open or file a new issue if necessary.

[Alex Browne]

This is still an issue. goose seems to be breaking certain go tools. For example, I have tests in several sub-packages. When I run go test ./... the test runner stops when it hits the db sub-package and does not run my tests. This is the output I get:

runtime.main: call to external function main.main
runtime.main: undefined: main.main