rpc

rpc copied to clipboard

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

hit this today also.

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.

hit this also.

(Deleted a comment that wasn’t constructive)

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

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
)

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

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

@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.

@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$

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

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

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

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

github.com/gorilla/[email protected]+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?

@harshavardhana, https://github.com/golang/go/issues/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).

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

@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, 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

• 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

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

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.

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

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

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.)

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