Stale subpackage binary breaking build about godep

[kr]

Ah, I have an idea for what this could be.

[bgentry]

@kr so what's your idea? :)

[kr]

Uh, I left that comment on my phone on a train and then forgot to follow up. Now I don't remember what the idea was.

Maybe something to do with git setting timestamps in the past during a checkout, but I doubt that would explain this case since I know hk has had commits since Jan 17.

It's hard to understand what's going wrong here. The command you ran godep go build is really just doing the equivalent of:

$ GOPATH=/path/to/hk/Godeps/_workspace:$GOPATH go build

[danp]

Is this a dup of #45?

[bgentry]

I don't think so? #45 is related to stale imports. This appears to be subpackages that are imported from the global Go path instead of the one set up by godep.

Maybe they are related or caused by the same thing, I'm not sure :)

[harshavardhana]

https://github.com/tools/godep/blob/master/get.go#L50 - i cannot help but wonder why is "go install" necessary for "godep get" ?

[freeformz]

Every time I've tracked these things down in the past it was because of the go tool using the wrong cached package file from outside. rewrites and/or vendor directory solve this AFAIK, so those should be used instead. Closing for now. If I'm way off base and/or we can reproduce with go 1.5* and current godep please re-open. Thanks!

[bgentry]

I'm almost positive this used to happen to me even with rewrites. But I'm
not using godep regularly enough right now to say if it's still an issue.

On Friday, September 11, 2015, Edward Muller [email protected]
wrote:

Every time I've tracked these things down in the past it was because of
the go tool using the wrong cached package file from outside. rewrites
and/or vendor directory solve this AFAIK, so those should be used instead.
Closing for now. If I'm way off base and/or we can reproduce with go 1.5*
and current godep please re-open. Thanks!

—
Reply to this email directly or view it on GitHub
#55 (comment).