dep init fails if in not in $GOPATH[...]/src/{somedir..}

[pbennett]

If GOPATH is foo/bar/ then running dep init from /foo/bar/src
yields:
determineProjectRoot: /foo/bar/src not in any $GOPATH
yet it most certainly is in the GOPATH.

I'll leave the commentary off about why I want this, but if this is going to be disallowed for now, a better error is needed.

[Mahito]

I could got same issue.

% echo $GOPATH
/Users/mahito/.go
% cd $GOPATH/src/sandbox
% dep init  
% ls
lock.json      manifest.json
% cd ..
% dep init
determineProjectRoot: /Users/mahito/.go/src not in any $GOPATH

This issue is happened every time in $GOPATH/src.
https://github.com/golang/dep/blob/master/context.go#L115 create srcprefix($GOPATH/src/) .
Next line compare path ($GOPATH/src) and srcprefix($GOPATH/src/) and get false, because len(path) is less length than len(srcprefix).

[machiel]

Yes, I've got the same issue, for private projects we work with $GOPATH as the project git root. Trying to do a dep init in $GOPATH yields:

determineProjectRoot: $GOPATH not in any $GOPATH

Though I was told this isn't the intended way of using the tool though, so it might be out of scope.

[sdboyer]

I think this approach to things should work fine, though because it's not a design case we've had in mind, there's likely to be at least a few hinky issues related to the base project root being empty. (Yeah...I can think of a few now.) The only important note to make is that the resulting repository will be useless for anyone trying to import it...but I imagine that's not a concern for anyone taking this approach.

To be clear - this approach means that dep will ensure there is exactly one version of all dependencies in your system, and all of them will be managed as a group. In general, if you leave all your third-party deps under vendor/, and keep all the stuff you actually work on (your monorepo-ish) directly in GOPATH not under vendor/, then this oughtta be OK.

At minimum, we need a better error here. Ideally, we'd support this as a first-class use case.

[tro3]

Yeah, this looks related to #201. I'll add an integration test for the cases described above then clean up the code.

[tro3]

Actually, this is not the same issue as #201 after all. This is more of a defintion question. The dependency import path is calculated as everything past $GOPATH/src, becuase that is where Go will look for the imports anyway. So if you start a project in $GOPATH/src, it can't figure out the import path. (I'm a little curious what $GOPATH/src/src would do.) I am too new to the subtleties of the Go import model to be able to make a call here, but it does sound to me like starting a repo directly in $GOPATH goes against the opinion of the tool, which assumes a $GOPATH/src, $GOPATH/pkg, $GOPATH/bin?

[machiel]

Just to clarify, I don't put my sourcecode directly in GOPATH.

My tree for most of my projects look somewhat like this: (Or vendor directly in GOPATH, if I use gb)

Hope this clear some things up :)

$GOPATH
├── bin
├── pkg
├── resources
│   ├── config
│   ├── templates
│   └── uploads
└── src
    ├── web
    ├── mail
    ├── notifier
    ├── server
    └── vendor

[sdboyer]

@tro3 yeah, this issue describes an alternate use pattern to what's typical; @machiel's description is a good description of one variant of it. It can work within the general model of dep, sliding through on a technicality (actually, more like a door-left-carefully-ajar).

However, fixing the handling to make the "GOPATH/src as root" case work is more involved, more or less because of what you note - there is no import path to figure out. Even once we solve it in dep, gps is going to need a bit of special handling for empty root import paths to support this case.

...and, actually, some other things, too. Ugh. I need to open an issue on gps for it.

[tro3]

Oh, I see. Actually, I kind of like that use case, though presumably $GOPATH is then set per-project. (Still a newbie, here.)

So if it works as-is for $GOPATH (thru the door left ajar :-)) and as intended for $GOPATH/src/x, maybe just a better error message for dep init run in $GOPATH/src is needed? In any case, #201 is a different beast. If you want an explicit error called for this case, let me know and I'll add.