Importing local packages fails (unrecognized import path) about heroku-buildpack-go HOT 7 CLOSED

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

from heroku-buildpack-go.

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?

from heroku-buildpack-go.

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.

from heroku-buildpack-go.

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.

from heroku-buildpack-go.

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.

from heroku-buildpack-go.

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.

from heroku-buildpack-go.

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! :)

from heroku-buildpack-go.