Giters

bufbuild / buf

The best way of working with Protocol Buffers.

Home Page:https://buf.build

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error installing buf via go install

IDispose opened this issue · comments

commented

Running the following command
go install github.com/bufbuild/buf/cmd/buf

results in

# github.com/bufbuild/buf/private/pkg/protosource
/Users/userid/go/pkg/mod/github.com/bufbuild/buf@v1.29.0/private/pkg/protosource/file.go:146:39: f.fileDescriptor.GetOptions().GetPhpGenericServices undefined (type *descriptorpb.FileOptions has no field or method GetPhpGenericServices)

As part of CI pipeline, this step breaks the build. How do I fix this?

commented

This happens because when using go install without specifying a version, Go will use your go.mod file to handle version selection. Go uses Minimal Version Selection (MVS) which, in brief, selects the newest version of all dependencies. This is usually not an issue because Go packages are generally not supposed to change in incompatible ways while keeping the same identity (which is why v2 and v1 packages, for example, will have different import paths.) Unfortunately, the Go protobuf packages change in incompatible ways at the same import path.

Because of this, you can't reliably use go.mod for version selection of the buf tool (or any Go CLI tool), because it will pull in incompatible packages in some cases.

There are two primary solutions for this problem (true for all Go CLI tools, but using buf here as an example):

  • Use go get github.com/bufbuild/buf@main to update your local go.mod version of github.com/bufbuild/buf to a pre-release version. This will give you a new enough version of buf that it will no longer succumb to this issue.

  • Preferably, stop using this pattern to version the buf tool. This is also pretty easy, thankfully: you can use a command like go install github.com/bufbuild/buf/cmd/buf@v1.29.0 - the version will cause the Go tool to ignore the go.mod file entirely, and thus the versions of Buf dependencies will be the exact ones that we intend, which should prevent this from ever breaking. MVS does not bring any benefits for versioning of tool dependencies, and causes problems with some other tools, too (like golangci-lint, which also doesn't recommend this practice for similar reasons.)

Hope that helps! Let us know if you have further problems.