Importing local packages fails (unrecognized import path)

[antonholmquist]

I'm trying to deploy a project with that uses a local package but it fails. It builds on my computer with no issues.

Part of the deploy log:

imports github.com/lib/pq
imports code.google.com/p/go.crypto/blowfish
imports myproject/api/session: unrecognized import path "myproject/api/session"

Do this buildpack assume that all packages can be downloaded with go get? Can it not use packages that are bundled with the app?

Would be great if someone could shed some light on this :)

[kr]

What does go list print when you run it in your project?

[antonholmquist]

It shows there are no .go files in the directory, which is true.

I have the entire workspace in the repo. My opinion is that external dependencies should be part of the repo and I would therefore like to structure it this way. I suspect that this may not be the way that the buildpack is designed to work?

What is your opinion on this?

[kr]

Much has been written on this topic in the context of Go. You can search the golang-nuts mailing list, or search Google to find blog articles about it.

My recommendation is to use a standard Go workspace, as described on https://golang.org/doc/code.html#Workspaces. Note the location of the .git directories in the example. It is generally a mistake to have a src directory that you create by hand in a Go project's repo.

Then, to make sure all your dependencies are contained within the repo, use a vendoring tool such as godep.

[antonholmquist]

Thank you for the answer!

I can definitely understand why many people really like the idea of using godeps, but I can not agree that it is generally a mistake to have a src directory in a Go repo. I don't agree with the idea of having all dependencies outside the repo is a good one. Github is a stable service today and for many years to come, but what if it some users with important repos will cancel their accounts in a couple of years? Or if Github itself not survive for another 10 years? That would break dependencies for a lot of projects. That's why I prefer to keep all dependencies inside the repo.

Would you be open to support my use case too, or are you determined to stay with godeps only? And by the way, thank you for the good work you already put into this project.

[kr]

I can not agree that it is generally a mistake to have a src directory in a Go repo.

That's just how the go tool was designed. I still suggest following the official instructions and example published by the Go team.

Github is a stable service today and for many years to come, but what if it some users with important repos will cancel their accounts in a couple of years? Or if Github itself not survive for another 10 years? That would break dependencies for a lot of projects. That's why I prefer to keep all dependencies inside the repo.

That's why people use tools such as godep. See also https://www.youtube.com/watch?v=myCHCXFFTPY for more on why it is a good idea to include your dependencies' source code in your repo (so called "vendoring").

Would you be open to support my use case too, or are you determined to stay with godeps only?

You absolutely don't have to use godep with this buildpack. I'm just suggesting that if you care about reproducibility, then you should really consider vendoring your dependencies. See https://camlistore.org/code for an example of a project that does vendoring without godep.

[antonholmquist]

Okay. So now I get it. I did never understand that godep actually solves my problem of not having external dependencies. I'm fairly new to Go and it really takes some time grasp the concept of Go workspaces (and godep). This is what I have been looking for and I haven't been able to find it, despite googling.

Thank you for taking your time to teach me. Excellent video.

[kr]

You're welcome! Sorry it was so difficult to find the information you were looking for. I hope the rest of your experience with this buildpack is more pleasant! :)