overlapping packages are not able to be updated

[jmhodges]

With godep version: godep v63 (darwin/amd64/go1.6.2)

I added some code that added go grpc to my repository (and so, golang.org/x/net/http2 was added).

But then godep save failed and the godep update it told me that there was nothing for it to do:

$  godep save ./go/...
godep: cannot save golang.org/x/net/http2 at revision 7e42c0e1329bb108f7376a7618a2871ab90f1c4d: already have golang.org/x/net/context at revision 35ec611a141ee705590b9eb64d673f9e6dfeb1ac.
Run `godep update golang.org/x/net/context' first.
$  godep update golang.org/x/net/context
 godep: no packages can be updated

Here's a quick grep of my Godeps.json:

$  cat Godeps/Godeps.json  | grep -A 1 'x/net'
            "ImportPath": "golang.org/x/net/context",
            "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"
--
            "ImportPath": "golang.org/x/net/context/ctxhttp",
            "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"
--
            "ImportPath": "golang.org/x/net/html",
            "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"
--
            "ImportPath": "golang.org/x/net/html/atom",
            "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"

Running go get -u -a golang.org/x/net/... per a comment in #335 and trying save and update again changed nothing.

[jmhodges]

Oh, I missed the second half of that comment.

It's necessary to also run godep update -v golang.org/x/net/.... It seems like maybe overlapping packages could be detected.

One plausible way to do that is to encode more information in Godeps.json such as the path the package is relative to the repo it's in. gvt does this.

[freeformz]

It looks like you have a newer version of golang.org/x/net in your GOPATH. Since godep works off what's in the GOPATH you need to 'godep restore' before saving new deps or this can happen. I'd like to get away from having to do that, but I'm not sure the right UI for it.

The error / help text should be clearer as well.

Thanks for the report.

Sent from my iPhone

On May 5, 2016, at 15:10, Jeff Hodges [email protected] wrote:

With godep version: godep v63 (darwin/amd64/go1.6.2)

I added some code that added go grpc to my repository (and so, golang.org/x/net/http2 was added).

But then godep save failed and the godep update it told me that there was nothing for it to do:

$ godep save ./go/...
godep: cannot save golang.org/x/net/http2 at revision 7e42c0e1329bb108f7376a7618a2871ab90f1c4d: already have golang.org/x/net/context at revision 35ec611a141ee705590b9eb64d673f9e6dfeb1ac.
Run `godep update golang.org/x/net/context' first.
$ godep update golang.org/x/net/context
godep: no packages can be updated
Here's a quick grep of my Godeps.json:

$ cat Godeps/Godeps.json | grep -A 1 'x/net'
"ImportPath": "golang.org/x/net/context",

"Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"

        "ImportPath": "golang.org/x/net/context/ctxhttp",
        "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"

        "ImportPath": "golang.org/x/net/html",
        "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"

        "ImportPath": "golang.org/x/net/html/atom",
        "Rev": "35ec611a141ee705590b9eb64d673f9e6dfeb1ac"

Running go get -u -a golang.org/x/net/... per a comment in #335 and trying save and update again changed nothing.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[jmhodges]

Great!

As data for future decisions, I'd actually intentionally made sure to install grpc with go get -u -a because I wanted godep to update all of them and was surprised when it got stuck. So, there was an intentional "vendor grpc and update my matching already vendored packages" desire.

The gb-vendor/gvt style of including a bit more information in the manifest is not bad. They include the directory thing I mentioned above which could be used to make smarter error messages (at least), but also the "original" branch which would help with #453. Might be there's some more things that are solved by those bits of data, too.

Until the restore problem gets fixed, I have a hard time telling others to use it. Which is fine, btw! Not trying to be all "do this thing or else", but just giving data for future decision making. We've got workarounds until things are a little easier in the future!

Thanks for the code! It's been great.

[freeformz]

I am in the middle of rewritting update, so let's see if I can also tackle some of this ...

I'm not sure what you mean wrt "recording the path". I'm not familiar with gvt, so I'll have to play with it. FWIW: Go packages are path based already. There is code in godep to figure out the root repo for a given package, so godep already has that info. It's just the way things are stringed together right now is sub optimal.

Before you did a go get -u -a did you do a godep restore?

Basically I'm trying to figure out a starting state to replicate this issue.

[freeformz]

PS: Thanks for the report. ;-)

[jmhodges]

Oh, yeah, by relative path, I mean, for example, the package is "github.com/google/protobuf/proto" so the extra relative path info written down is "/proto" because the Git repo root is the "protobuf" directory. It can be used to detect when packages that overlap all are in the same repo.

I was at master everywhere and my GOPATH deps all had a newer sha than the ones in Godeps.json.

[freeformz]

Yeah. that's why you need to godep restore before saving new deps and/or updating deps. Basically the workflow (both fortunately and unfortunately) is:

$ godep restore
$ cd $GOPATH/src/<package you want to update>
$ git checkout master
$ git pull origin master (or checkout whatever you want to update to)
$ cd $GOPATH/src/<package I am working on>
$ godep update <package you want to update>/... (most likely need the /... atm)

And yes, that kinda sucks.

I am thinking of side-stepping this with a godep get <package>[@<version/sha> command, which would just pull the package directly into vendor/ (or the workspace), including deps. It <version/sha> would default to origin/HEAD unless specified. There is already a godep get, but it's a small, almost useless wrapper around go get.

Thoughts?