gorilla/rpc

v2 go mod incompatibility

rocketbitz opened this issue · 26 comments

rocketbitz commented

The RPC v2 module is never downloaded, I believe because of the v2 in the path, go mod believes it is a v2 of gorilla/rpc, not a separate package.

$ go mod vendor
go: finding github.com/gorilla/rpc/v2/json2 latest
go: finding github.com/gorilla/rpc/v2 latest
go: downloading github.com/gorilla/rpc/v2 v2.0.0-20180618141230-5c1378103183

$ go vet ./...
cannot find module for path github.com/gorilla/rpc/v2
Deleted user commented

hit this today also.

  • 👎1
elithrar commented

Noted. This won't be straightforward to rectify - because we have to change the path, which will break existing users (or both!)

  • We "break" the v2 path in a new tagged release, removing the existing "v1" code. This will break those without a module-aware Go toolchain still relying on those paths.
  • Move to a v3 (tagged) and duplicate v2 in both the root and /v2 (duplicate, hugely error prone, maintenance burden)
  • ???

I'm not aware of other great options here, and am open to suggestions.

  • 👍1
dangerousvasil commented

hit this also.

  • 👎2
elithrar commented

(Deleted a comment that wasn’t constructive)

Deleted user commented

Workaround: Add +incompatible to version tag in go.mod manually.

jbrukh commented

Thanks @stek29, can you please post an example of how to define +incompatible require clause here?

Edit:

I was able to do it as follows:

require (
  github.com/gorilla/rpc v1.2.0+incompatible // indirect
  github.com/alpacahq/marketstore v3.2.6+incompatible
)
Deleted user commented

@jbrukh yup, that's what i've meant.

kisielk commented

Honestly we could just move it all to an entirely new repo path and close this one. eg: github.com/gorilla/rpc2.

Deleted user commented

@kisielk Agreed. I was quite confused when I realized that rpc/v2/json is in fact JSON RPC 1, not 2, and v2 refers to library itself.

bcmills commented

@rocketbitz, what did you run before go mod vendor? I don't see any incompatibility here.

example.com$ go1.13beta1 mod init example.com
go: creating new go.mod: module example.com

example.com$ go1.13beta1 get -d github.com/gorilla/rpc/v2/json2
go: finding github.com/gorilla/rpc/v2/json2 latest
go: finding github.com/gorilla/rpc/v2 latest
go: finding github.com/gorilla/rpc v1.2.0+incompatible
go: downloading github.com/gorilla/rpc v1.2.0+incompatible
go: extracting github.com/gorilla/rpc v1.2.0+incompatible

example.com$ go1.13beta1 list github.com/gorilla/rpc/v2/...
github.com/gorilla/rpc/v2
github.com/gorilla/rpc/v2/json
github.com/gorilla/rpc/v2/json2
github.com/gorilla/rpc/v2/json2/testapp
github.com/gorilla/rpc/v2/protorpc

example.com$ go1.13beta1 test github.com/gorilla/rpc/v2/...
ok      github.com/gorilla/rpc/v2       0.038s
ok      github.com/gorilla/rpc/v2/json  0.084s
ok      github.com/gorilla/rpc/v2/json2 0.053s
?       github.com/gorilla/rpc/v2/json2/testapp [no test files]
ok      github.com/gorilla/rpc/v2/protorpc      0.047s

example.com$
bcmills commented

Ah, now I see it. This triggered golang/go#33099 (and was masked by golang/go#32805) using go1.13beta1, but is fixed at head.

example.com$ GOPROXY=direct go1.13beta1 get -d github.com/gorilla/rpc/v2/json2
go: finding github.com/gorilla/rpc/v2/json2 latest
go: finding github.com/gorilla/rpc v1.2.0
go: finding github.com/gorilla/rpc/v2 latest
go: downloading github.com/gorilla/rpc v1.2.0
go: downloading github.com/gorilla/rpc/v2 v2.0.0-20190627040322-27d3316e212c
go: extracting github.com/gorilla/rpc v1.2.0
go get github.com/gorilla/rpc/v2/json2: missing github.com/gorilla/rpc/go.mod and .../v2/go.mod at revision 27d3316e212c

example.com$ GOPROXY=direct gotip get -d github.com/gorilla/rpc/v2/json2
go: finding github.com/gorilla/rpc/v2/json2 latest
go: finding github.com/gorilla/rpc/v2 latest

example.com$ go list -m all
example.com
github.com/gorilla/rpc v1.2.0
bcmills commented

Works fine with gotip as-is, without the +incompatible suffix:

example.com$ gotip version
go version devel +f518a96e Fri Jul 19 20:08:48 2019 +0000 linux/amd64

example.com$ GOPROXY=direct gotip get -d github.com/gorilla/rpc/v2/json2
go: finding github.com/gorilla/rpc/v2/json2 latest
go: finding github.com/gorilla/rpc/v2 latest
go: finding github.com/gorilla/rpc v1.2.0
go: downloading github.com/gorilla/rpc v1.2.0
go: extracting github.com/gorilla/rpc v1.2.0

example.com$ cat go.mod
module example.com

go 1.13

require github.com/gorilla/rpc v1.2.0 // indirect
rocketbitz commented

Nice, so looks like it's resolved in latest Go release?

bcmills commented

Will be resolved in the next Go release, yes. (gotip or whatever build is cut next after go1.13beta1.)

harshavardhana commented

github.com/gorilla/rpc@v1.2.0+incompatible: unexpected status (https://proxy.golang.org/github.com/gorilla/rpc/@v/v1.2.0+incompatible.info): 410 Gone

Some issue in our builds started happening any clues?

bcmills commented

@harshavardhana, golang/go#32805 was just resolved, and the version v1.2.0+incompatible was removed because it is invalid (v1.2.0 is not, in fact, incompatible).

harshavardhana commented

This seems to have broken the builds @bcmills I can't seem to get my CI's to build with go1.12.7

bcmills commented

@harshavardhana, go1.12.7 doesn't even use proxy.golang.org by default. (You have to set GOPROXY explicitly for it to take effect.)

Fundamentally, there are two workarounds and one long-term fix.

  • The two workarounds are to add a replace directive as described in https://tip.golang.org/doc/go1.13#version-validation, or to use go1.12.7 without proxy.golang.org.
  • The long-term fix is to remove the dependency on the invalid version, and instead use the corresponding valid version (v1.2.0, not v1.2.0+incompatible).
harshavardhana commented

@harshavardhana, go1.12.7 doesn't even use proxy.golang.org by default. (You have to set GOPROXY explicitly for it to take effect.)

Correct we did set that for faster builds @bcmills

harshavardhana commented
  • The long-term fix is to remove the dependency on the invalid version, and instead use the corresponding valid version (v1.2.0, not v1.2.0+incompatible).

We don't depend on it anyways it's just automatically added by go mod and we see that we have no control on it. Since GO111MODULE=on auto adds and removes things when doing go build from go.mod

bcmills commented

If you add v1.2.0 to your go.mod file explicitly, it should not be replaced with v1.2.0+incompatible automatically.

harshavardhana commented

If you add v1.2.0 to your go.mod file explicitly, it should not be replaced with v1.2.0+incompatible automatically.

I did that and it does get replaced as soon as I do make install :-) - in any case, I used the replace directive thanks for that @bcmills it seems to help and work.

bcmills commented

make install is not the go command, so I can't help you with that part. (If it were go install, perhaps...) 🙂

harshavardhana commented

make install is not the go command, so I can't help you with that part. (If it were go install, perhaps...)

Yeah it is like this

@goproxy=https://proxy.golang.org GO111MODULE=on GOFLAGS="" CGO_ENABLED=0 go build -tags kqueue --ldflags $(BUILD_LDFLAGS) -o $(PWD)/minio 1>/dev/null

bcmills commented

It occurs to me that the v1.2.0+incompatible might be coming from your transitive dependencies. If so, go mod graph should be able to tell you which one(s), and from there you can send a PR to change them to use the valid version. (But that will presumably take a bit of time, so you'll need the replace workaround in the interim anyway.)

harshavardhana commented

It occurs to me that the v1.2.0+incompatible might be coming from your transitive dependencies. If so, go mod graph should be able to tell you which one(s), and from there you can send a PR to change them to use the valid version. (But that will presumably take a bit of time, so you'll need the replace workaround in the interim anyway.)

Yes that is what we did and it works until we move to go1.13