dep init fails in subdir

[alexflint]

If I run dep init at the top of my repository (ie $GOPATH/github.com/xxx/yyy) then everything works fine. But the repository I'm working in contains mostly c++, and all the Go code actually lives in a subdirectory, so I'd also like Gopkg.lock, Gopkg.toml, and the vendor directory to live under that subdirectory. But if I run dep init within that repository then I get a bunch of failed constraint messages.

[carolynvs]

dep is designed to only be run at the project root. We have https://github.com/golang/dep/issues/193#issuecomment-276051825 open to show a better error message when dep is run from a sub-directory.

@sdboyer Is it always the case that project root = root of repo? I tried making a simple project and put my go code in a subdir and ran dep init from there and nothing blew up. I assume that's because it was too simple to run into problems?

[sdboyer]

Is it always the case that project root = root of repo?

It doesn't _have_ to be - strictly speaking, you can manually create a Gopkg.toml in any subdirectory, then dep ensure will treat that as the project root. Or dep init at the root, then move it into the desired subdir. This is fine in a monorepo-type environment, or if there's no expectation that the project will ever be _used_ as something else's dependency.

However, moving the Gopkg.toml out of the root will result in any constraints declared in that project/repo to be ignored by the tool, because we don't search for a Gopkg.toml. We don't do that search because it would introduce complexity and associated new failure modes in three new dimensions:

1. Import paths are no longer independently sufficient for determining project root location
2. Root location(s) can vary from one version to the next
3. It is no longer straightforward to determine which packages in a repo are covered by a manifest's constraints; all possible decisions (as far as I've been able to think through it) have some rather nasty consequences

(this deserves an FAQ item - assigning to me for that)

[machzqcq]

The below results in this for me. Is this related to the same issue ?

mymac:go-experiments pmacharl$ go get -u github.com/golang/dep/cmd/dep
mymac:go-experiments pmacharl$ echo $GOPATH
/Users/pmacharl/code/go;/Users/pmacharl/git-projects/go-experiments
mymac:go-experiments pmacharl$ dep init
"/Users/pmacharl/git-projects/go-experiments" not in any GOPATH: "/Users/pmacharl/git-projects/go-ex
periments" not in any GOPATH

I am able to run go build and go install without any issues.

[sdboyer]

@machzqcq nope, that's a different thing. First, your cwd has to be under GOPATH/src - and then some further subdir - #148.

[alexflint]

So just to confirm: I created my Gopkg.toml in a directory that was not the root of my repository and ran all dep commands from that same directory, but that did not work (whereas when I moved those files to the root of the repo and re-ran the same command then everything worked as expected)

[ibrasho]

@alexflint Could you please provide more context? What commands did you try and what was the output (and error message if applicable)?

[smithaitufe]

Hi, let's assume this use case. I am building microservices. Is it better to maintain a single vendor folder in the root of the project or to allow each microservices folder to manage their dependencies?

I have discovered before stumbling upon this issue that dep init in a sub directory fails after a long wait.

What is the best approach?