Failures following heroku specific instructions

Issue #13 resolved
Shaun Duncan created an issue

Hi, I'm following the instructions regarding heroku usage for the goose binary. If I create an install_goose.go file as indicated, a local go get fails to build with the following:

install_goose.go:4:8: no Go source files in $GOPATH/src/bitbucket.org/liamstask/goose

I tried moving install_goose.go to a lib package in my app, but a git push heroku master fails with the same message. Any advice?

Thanks!

Comments (14)

  1. Liam Staskawicz repo owner

    Ah, the layout of the repo recently changed and I think that part of the docs was not updated - does import _ "bitbucket.org/liamstask/goose/cmd/goose" work?

  2. Shaun Duncan reporter

    Thanks for the quick reply. I had already tried that when looking through the source tree for goose, but I came up with the following error:

    ./install_goose.go:4: can't find import: "bitbucket.org/liamstask/goose/cmd/goose"
    

    This isn't really preventing me from doing anything, I should point out. A workaround for me was to export DATABASE_URL from heroku config, then run goose -env production up locally.

  3. Liam Staskawicz repo owner

    Hm - looks like a bit of strange behavior from the import directive.

    If the cmd has the same name as the repository, import fails as you reported. If I change the name of the cmd to another arbitrary name, it succeeds.

    I'll need to poke around a bit to figure out whether this is intended and, if so, what the recommended practice is.

  4. Liam Staskawicz repo owner

    Also, is there any other way to install goose on Heroku, other than through an import directive? Sorry, I don't use Heroku...

  5. Liam Staskawicz repo owner

    Any chance you previously built goose on that heroku instance before the repo layout changed?

    Can you remove any traces of goose from $GOPATH/bin and $GOPATH/pkg on that heroku instance and try again, with the updated import path (bitbucket.org/liamstask/goose/cmd/goose)?

    I did that locally, and was able to build and run a similar install_goose.go file successfully.

  6. Shaun Duncan reporter

    Unrelated: I had imported github.com/bmizerany/pq and that caused a sql.Register() panic since it looks like goose imports github.com/lib/pq. Just using libpq in my app solves that.

    I've taken your advice and remove build artifacts and tried again, but it doesn't appear the goose binary gets dropped anywhere on the heroku instance. But, that might just be a problem with the buildpack? I'll keep toying with it and let you know if I find anything. But like I said, I have a valid workaround now without requiring I build goose on the heroku instance.

  7. Liam Staskawicz repo owner

    That's surprising - when you run heroku run goose, is there any way to determine where that executable is?

    I suspect if you can locate that, and clear out the corresponding bin and pkg paths, it may resolve the issue.

  8. Shaun Duncan reporter

    Actually, I've done some more experimenting this morning and it looks like it actually might be a problem with the Go buildpack, and more specifically, the godep tool. That runs sandboxed go get calls, which doesn't drop the goose binary in $GOPATH/bin. If I use a custom fork of the buildpack and run a plain go get, the binary appears in $GOPATH/bin.

    So, I guess it's not really a goose problem after all. Changing the import path as you instructed got this working for me with the buildpack fork that doesn't use godep.

    Thanks for all the help! I'll probably an issue with the buildpack or godep.

  9. Liam Staskawicz repo owner

    Great - thanks for the update.

    If you consider this issue resolved, would you mind closing it out? Thanks!

  10. Log in to comment