update protobuf and grpc versions

[trung]

To support protobuf v3:

• protobuf lib version upgraded to 1.3.0
• grpc lib version upgraded to 1.18.0

There are some auto cleanup by go mod as the result.

I'm using go 1.11.12

› go test ./...
ok  	github.com/hashicorp/go-plugin	8.439s
?   	github.com/hashicorp/go-plugin/examples/basic	[no test files]
?   	github.com/hashicorp/go-plugin/examples/basic/commons	[no test files]
?   	github.com/hashicorp/go-plugin/examples/basic/plugin	[no test files]
?   	github.com/hashicorp/go-plugin/examples/bidirectional	[no test files]
?   	github.com/hashicorp/go-plugin/examples/bidirectional/plugin-go-grpc	[no test files]
?   	github.com/hashicorp/go-plugin/examples/bidirectional/proto	[no test files]
?   	github.com/hashicorp/go-plugin/examples/bidirectional/shared	[no test files]
?   	github.com/hashicorp/go-plugin/examples/grpc	[no test files]
?   	github.com/hashicorp/go-plugin/examples/grpc/plugin-go-grpc	[no test files]
?   	github.com/hashicorp/go-plugin/examples/grpc/plugin-go-netrpc	[no test files]
?   	github.com/hashicorp/go-plugin/examples/grpc/proto	[no test files]
?   	github.com/hashicorp/go-plugin/examples/grpc/shared	[no test files]
?   	github.com/hashicorp/go-plugin/examples/negotiated	[no test files]
?   	github.com/hashicorp/go-plugin/examples/negotiated/plugin-go	[no test files]
?   	github.com/hashicorp/go-plugin/internal/plugin	[no test files]
?   	github.com/hashicorp/go-plugin/test/grpc	[no test files]

[hashicorp-cla]

All committers have signed the CLA.

[syndbg]

This would be nice to have.

Any way we can get this merged upstream?

@notnoop

[jefferai]

Can you explain what you mean by support protobuf v3? This has always used v3.

[notnoop]

Protobuf has some internal versioning to check compatibility between the library and generated code. Currently, upstream protobuf at version 3[1], but not the version we depend on in go.mod[2].

I'm not too familiar with go mod to understand how declared dependency versions impact users of library though. I'd would have guessed that we should declared the least version we can depend on, and downstream applications can choose a specify a higher minor version and go mod can handle it well. Is that not the case?

[1] https://github.com/golang/protobuf/blob/v1.3.2/proto/lib.go#L944-L946
[2] https://github.com/golang/protobuf/blob/v1.2.0/proto/lib.go#L963-L969

[syndbg]

I've continued this over at #128 . There's nothing specific to protobuf3 support (since it's already there), only latest versions bump.

[jefferai]

I think you're misunderstanding the ProtoPackageIsVersionWhatever. That has nothing to do with protov2 vs proto3, it has to do with the internal version of the package's internal API.

What is the actual problem being solved here? I'm not against bumping deps, but what is the specific issue you're running into?

[trung]

Hi all, it took me sometimes to recall what issues i've ran into.

Basically if i compile my proto file using later version of proto gen for golang, the generated code has this line:

const _ = proto.ProtoPackageIsVersion3 // please upgrade the proto package

However, in protobuf 1.2.0 which comes with go-plugin doesn't have the const proto.ProtoPackageIsVersion3 causing compilation error. (looks like golang/protobuf#763)

Please checkout my simple project: https://github.com/trung/go-plugin-with-channels. If you remove the explicit protobuf and grpc dependencies in go.mod, you will see the compilation error:

proto/stream.pb.go:25:11: undefined: proto.ProtoPackageIsVersion3
make: *** [default] Error 2

Also it would be good to use context instead of golang.org/x/context through out the code. Although I was not able to reproduce the issue with this but I remembered encountering it once.

I'll promise to write better PR description next time :)

Thanks for creating a great library.

[jefferai]

Generally speaking I'm for keeping deps up to date. However there is a danger here:

Because of go modules minimum versioning algorithm, an update here will mean that all downstream users of this package will be forced to use the updated version. I worry that this will fix your problem but cause others elsewhere. I'm not sure though.

[trung]

I personally don't mind adding protobuf and grpc with later versions to overwrite the transitive 1.2.0 in go-plugin to solve my issue. I also noticed that, not sure if it's due to the same issue, Terraform and Vault go.mod also has later versions.

protobuf 1.3.0 release note and grpc 1.18.0 release note don't seem highlight anything about break changes so I assume it's backward compatible with 1.2.0.

Having said that, the call is yours. I respect your final decision on this.

[jefferai]

I'm at HC but don't really work with this lib much. @jbardin given the conversation above, what do you think? Other software also using protobuf and grpc may well already be using newer versions from other deps, so I think it's probably fine. Worse comes to worse people could fork off and use a fork with lower deps?

[jbardin]

I can't think of any major issues, and as mentioned earlier, Terraform and Vault both already pull in 1.3.x. This should probably be bumped to 1.3.2 if were going to update it.

It might be a good idea to tag a release on each side here, just to make it easier for others to reference, maybe 1.0.2 and 1.2.0?

[jefferai]

I think just 1.0.2 and 1.0.3. There's nothing backwards incompatible in the lib, it's just updated deps.

[mitchellh]

I'm going to just chime in that this is probably safe to do, I just tested some of our projects with a replace directive and updating proto lib and it was fine. I think if we bring it in with #135 and maybe some other PRs here (I'm doing a sweep and will bring up more for review) then we can mark the 1.1.0.

[mitchellh]

Talked to @jbardin and others at HEX. I updated to latest (1.3.4) and go mod tidy'd and merged.