Bootstrap dilemma of `buf`

[Hellseher]

Hi,

Following this issue bufbuild/protovalidate-go#279 (comment), it was suggested to build buf.build/gen/go/bufbuild/protovalidate/protocolbuffers/go with local buf plugin, while buf needs buf.build/gen/go/bufbuild/protovalidate/protocolbuffers/go https://github.com/bufbuild/buf/blob/v1.61.0/go.mod#L7 to be built giving us cycled dependencies which can't be bootstrapped.

Did you have any lower requirements for buf.build/gen/go/bufbuild/protovalidate/protocolbuffers/go or any other tools where buf is not used as dependency; or, maybe, the procedure of building buf with some optional inputs where buf.build/gen/go/bufbuild/protovalidate/protocolbuffers/go is not required.

Thanks

References

• Buf CLI: Generating with remote plugins https://buf.build/docs/generate/#generating-with-remote-plugins
• GNU Mes: Full Source bootstrap (an example of lower level bootstrap tooling) https://nlnet.nl/project/GNUMes-fullsource/
• cmd/go: do not allow the main module to replace (to or from) itself cmd/go: do not allow the main module to replace (to or from) itself golang/go#34417
• Circular Dependencies in Golang https://medium.com/@bytecraze.com/circular-dependencies-in-golang-e8437f16abef

[doriable]

So buf requires buf.build/gen/go/bufbuild/protovalidate/protocolbuffers/go for our lint rules to check protovalidate options, and we try to keep the packages on the CLI as up-to-date as possible. Do you mind elaborating why/how you are running into this issue, e.g. how you're pulling in the buf tool, etc.? The buf binary and its dependencies should be an isolated concern.