dep ensure failed to resolve project root

[ensonic]

> cd ~/go/src/app;
> ~/go/bin/dep ensure k8s.io/client-go@^2.0.0
... resolve project root: '/home/ensonic/go/src/app' is linked to another path within a GOPATH (/home/ensonic/go)

ll ~/go/src
total 40
drwxr-x--- 8 ensonic eng 4096 Apr 11 15:23 ./
drwxr-x--- 5 ensonic eng 4096 Apr 11 15:01 ../
lrwxrwxrwx 1 ensonic eng   76 Apr 11 15:23 app -> /home/ensonic/projects/foo/src/app/
lrwxrwxrwx 1 ensonic eng   76 Apr 11 12:12 apps -> /home/ensonic/projects/foo/src/apps/
drwxr-x--- 3 ensonic eng 4096 Mar 31 14:07 cloud.google.com/
drwxr-x--- 4 ensonic eng 4096 Mar 31 14:07 github.com/
drwxr-x--- 3 ensonic eng 4096 Mar 31 14:07 golang.org/
drwxr-x--- 5 ensonic eng 4096 Mar 31 14:07 google.golang.org/
drwxr-x--- 3 ensonic eng 4096 Apr 10 15:42 gopkg.in/
drwxr-x--- 5 ensonic eng 4096 Apr 11 10:49 k8s.io/

I don't think the error message is correct, neither can I understand it, not can I see what I can do to help the tool.

I now stopped using symlinks, but a 2nd path entry in GOPATH and it looking better.

[Civil]

I think I've got the same problem but on different stage.
My GOPATH consists of 2 paths:

$ echo $GOPATH
/Users/vsmirnov/go/gopath_third_party:/Users/vsmirnov/go/gopath:/Users/vsmirnov/gentoo/usr/lib/go/
$ dep init
determineProjectRoot: /Users/vsmirnov/go/gopath_third_party/src/github.com/go-graphite/carbonapi not in any $GOPATH

I use 2 GOPATH to separate internal git tree and external (gopath_third_party) one + system packages (gentoo/usr/lib/go).

It worked ok around 1 week ago.

[sdboyer]

(first, pinging @brianstarke 😄 )

@ensonic this first case seems odd, unless /home/ensonic/projects or /home/ensonic/projects/foo is ALSO a symlink, or if /home/ensonic/projects/foo is registered as its own GOPATH. If the latter is true, then it's the right error message - we don't support symlinking from one GOPATH into another, because it just didn't seem like a major use case, and we were trying to avoid letting the crazy leak in - #247 (comment)

@Civil So, if I'm reading that error correctly, you're trying to run dep init from /Users/vsmirnov/go/gopath_third_party/src/github.com/go-graphite/carbonapi? If so...yeah, that looks like a bug.

PS symlinks, wherefore art thou such an abomination

[Civil]

@sdboyer yes, I'm issuing dep init in that path and this is the error I'm getting out of it. If it'll help I can find last working commit.

[brianstarke]

Agreed with @sdboyer on the first case, @ensonic... in this case we're not really sure which path to use (the symlink or the real path) and didn't want to make the decision for you since that would set the expectation that it worked as expected and there's a 50% chance it didn't :) Prior to #247, you would have gotten the same error.

@Civil ... that definitely looks like a bug and definitely looks like my fault. Sorry! Ideally what I tried to do was to do nothing if no symlinks are involved. I'll look in to it.

[Civil]

From what I understand my bug is https://github.com/golang/dep/blob/master/context.go#L37-L52 in this part.

What happens here (on an example):
My working directory is: /Users/vsmirnov/go/gopath_third_party/src/github.com/Civil/carbonserver-flamegraphs
My GOPATHS are: [/Users/vsmirnov/go/gopath_third_party, /Users/vsmirnov/go/gopath, /Users/vsmirnov/gentoo/usr/lib/go/]

We are starting iterating over all GOPATHS. First iteration - we assign GOPATH=/Users/vsmirnov/go/gopath_third_party, but then for some reason we are not stopping iterating over and because next GOPATHS[1] is called '/Users/vsmirnov/go/gopath', our filepath.HasPrefix(wd, gp) will also return 'true' and reassign GOPATH variable.

I'll send a PR with a simple fix as an example.

Edit: #379

[ensonic]

I still don't under stand the 'is linked to another path within a GOPATH' part. The gopath is "/home/ensonic/go" and my actual code is under "/home/ensonic/projects/foo". The latter is not inside the gopath, I just linked it into the gopath.
Please note, that I stopped doing this and now use a GOPATH with two segments.

[sdboyer]

@ensonic yes, it seems like we do have a bug there. disallowing "linking to another GOPATH" is supposed to avoid the situation where you have multiple elements in your GOPATH, and a symlink points from one, into the other. We really need to have just one GOPATH that we operate on (in dep init - the only time we touch GOPATH)`.

It would appear our logic isn't doing that quite correctly, though. I'm pretty overwhelmed with other things at the moment, but if you have a reproducible case that you could turn into a PR (or at least a test that simulates it), that would be amazing.

[ibrasho]

Closing this since #641 is merged. We should be handling symlinks according to #247 (comment).