Hello! buf looks neat. :-)

Worth noting in your style guide docs, you reference our style guide that we are in the process of deprecating in favor of AIPs.

Here are the new links:

The last component of a package should be a version per the rules of the Google APIs Design Guide. (Why?)

We now cover this in AIP-191.

Files should be ordered in the following manner (this matches Google's current recommendations):

We now cover this in AIP-191.

Name fields after their type as much as possible. For example, for a field of message type FooBar, name the field foo_bar unless there is a specific reason to do otherwise. Another good resource to consult on field naming is the Google APIs Design Guide.

We now cover this in AIP-140.

I've discovered buf by reading about https://github.com/uber/prototool which appear to be a uber backed project. Could you add a statement in your repositories about whether or not uber actively support buf?

Hey folks! Really love the tool; I appreciate the json output as it's much easier to work with than the proto descriptors.

Unfortunately, buf seems to be omitting custom options from rpcs; for example, the following proto definition:

syntax = "proto3";

package test;

import "google/protobuf/descriptor.proto";

message TestRequest { }
message TestResponse { }

message MyOption {
  string setting = 1;
}

// Test Service
service TestService {
  rpc TestMethod(TestRequest) returns (TestResponse) {
    option (myoption) = {
      setting: "something"
    };
  };
}

extend google.protobuf.MethodOptions {
    MyOption myoption = 50000;
}

Results in an image containing this:

    {
      "name": "test.proto",
      "package": "test",
      "dependency": [
        "google/protobuf/descriptor.proto"
      ],
      "messageType": [
        {
          "name": "TestRequest"
        },
        {
          "name": "TestResponse"
        },
        {
          "name": "MyOption",
          "field": [
            {
              "name": "setting",
              "number": 1,
              "label": "LABEL_OPTIONAL",
              "type": "TYPE_STRING",
              "jsonName": "setting"
            }
          ]
        }
      ],
      "service": [
        {
          "name": "TestService",
          "method": [
            {
              "name": "TestMethod",
              "inputType": ".test.TestRequest",
              "outputType": ".test.TestResponse",
              "options": {}
            }
          ]
        }
      ],
      "extension": [
        {
          "name": "myoption",
          "number": 50000,
          "label": "LABEL_OPTIONAL",
          "type": "TYPE_MESSAGE",
          "typeName": ".test.MyOption",
          "extendee": ".google.protobuf.MethodOptions",
          "jsonName": "myoption"
        }
      ]
  }

Notice that it recognizes the extension, but it's not included in the rpc's options object, and indeed the string "something" doesn't appear in the image.json anywhere at all.

Is this expected behaviour? It'd be really nice to have these options captured in the image output in one way or another, since I need to run some checks and analysis on these options in my project.

Thanks for your help and all the work you do!

The buf check breaking command has support for branches and tags when checking against a git repository input. I want it to accept an arbitrary git reference, like refs/remotes/origin/master or refs/pull/3/head.

In my humble opinion, if you're not afraid of breaking backwards compatibility, it makes sense to remove branch and tag flags, since they're just a strict subset of providing the reference directly (and removing them would simplify some of the flag logic).

Do you have any plans to make it easier to contribute or load (private) custom lint checkers?

I really like where buf is going, but the lint-rules are already too rigid. E.g. I want to use the PACKAGE_VERSION_SUFFIX but we have a v1experimental convention it doesn't support and we need the flexibility to change it to something else in the future.

We also have specific needs covering which options are required (e.g. c# namespaces etc.)

Even more, we have an ambitious style guide which I would like to encode in automatic rules. Things ranging from what to name fields, which annotations to use etc.

Without built-in support for loading extensions, my options might be to either fork buf or try to find a different tool.

I have similar concerns about the bc checks.

Hello again!
I have been going over the buf docs out of curiosity, and thought I would let you know about one thing I have encountered for breaking changes.

Protobuf in a couple of languages (my memory fails me right now, but I think it is Java and PHP) adds more than one helper method for fields using the wrapper types (e.g. google.protobuf.BoolValue):

google.protobuf.BoolValue foo = 1;

Generates something like (syntax intentionally using Go because I am more familiar, but Go does not do this):

func GetFoo() BoolValue
func GetFooValue() bool

This creates an interesting backwards compatibility corner case if someone does:

google.protobuf.BoolValue foo = 1;

// This one (I think) got added later, changing the original GetFooValue() method
// to GetFooValue2()
Anything foo_value = 2;

For awhile, this would make code that did not compile, but the protobuf team fixed that about ~6 months ago when (after who knows how long) a team actually managed to stumble into this. So now it appends a 2 (not kidding) to one of the methods, and I truly and honestly can not remember which one.

In fairness, this rule may not be worth adding to buf, but your docs say "if we missed anything, tell us urgently", so I figured I would point it out. It is worth noting that I am responsible for ~80% of API reviews in Google Cloud, and have reviewed literally hundreds of APIs and thousands of protos, and this has been hit exactly one time. So it really is a corner case.

Letting you know, so you can decide whether to include or not. :-)

The check as-implemented just checks to see if the string .. exists anywhere in the full relative filepath, which does not necessarily mean the path is outside of the context. E.g., a directory or file could be named this..is..a..file.

I'm running into this now, where it seems like a node_modules directory somewhere in our repo contains a file called ..d and is causing buf to complain.

My case should be solvable with excludes, but in general a more robust check should maybe be used here?

Is this expected? If so, what is the recommended way to delete a service?

Config:

build:
    roots:
        - proto/
lint:
    use:
        - DEFAULT
        - FILE_LOWER_SNAKE_CASE
breaking:
    use:
        - FILE
    ignore:
        - company/proto/iam/v1test

Steps:

• Delete: company/proto/iam/v1test.
• Run: buf check breaking --against-input .git#branch=master

Result:

:1:1:Previously present file "company/proto/iam/v1test/service.proto" was deleted.

Expected:

Breaking change detector to pass.

Hi 👋 The goal of the project resonates me. I really appreciate it.

The doc mentions it could be used as an input to protoc. But, I'm not able to find any more information. Could it be clarified? The doc anywhere does not mention how the image file is used.

People (at least I) will be interested in generating stubs without typing protoc --whatever_out -I.... So, I expect to see such an example, but I was not able to find the information.

I'm also happy to help if I could improve the documentation.

Details in #13.

Summary:

docker run \
--volume="/home/user/code/myproject/buf-repro:/work" \
--workdir="/work" \
bufbuild/buf:latest \
check breaking --against-input '.git#branch=master'
could not clone .git: exec: "git": executable file not found in $PATH

Attached repository can reproduce. make lint to demonstrate that the tool works for linting. make test to reproduce the issue.

repro-example.tar.gz

Found the error on #16... the wrong docker run command from the docs

https://buf.build/docs/migration-prototool#docker

Missing the : in the docs

Fix

docker pull bufbuild/buf
docker run --volume "$(pwd):/workspace" --workdir "/workspace" bufbuild/buf check lint

We've found that it's easier to support both local and CI break checking when we use the git source instead of the SSH source (the SSH source might be easier to use if it integrated with ssh-agent to not require providing the key passphrase).

When using the git source, we want to break check against origin/master.

We currently do it like this:

.PHONY: buf-check-breaking
buf-check-breaking: $(buf)
	@git fetch origin master
	@git branch --no-track -f buf-break-check origin/master
	$(buf) check breaking --against-input '.git#branch=buf-break-check'
	@git branch -D buf-break-check

Would it make sense to say .git#branch=origin/master here?

Currently the result is:

 $ buf check breaking --against-input '.git#branch=origin/master'
could not clone .git: couldn't find remote ref "refs/heads/origin/master"

If I have my proto files in a directory ./proto and my dependencies in a directory ./proto-vendor and have a buf.yaml file like this:

build:
  roots:
    - proto
    - proto-vendor

I end up with this error root proto-vendor is within root proto which is not allowed which I don't really understand. Renaming proto-vendor topvendor solves the issue, but I think this is a bug or an under documented specification.

https://github.com/uber/prototool has updated their readme to redirect users to buf (uber/prototool@71e91a9). Which somewhat implies the eventual death of prototool, which means the death of some features that buf is missing (intentional or not).

buf's current position on formatting proto files is that it's outside of the scope of the tool, or currently more troublesome than the value of the feature: https://buf.build/docs/lint-checkers#formatting

This is a fine position, but I think it's worth tracking an issue against this for whenever someone takes on a "correct" parsing & formatting implementation.

Documentation says

Note that buf does not allow comment-driven ignores.

While I understand the reasoning, I still suggest reconsidering. For example I just finished integrating buf checks in a code base which is a large monorepo. Most protos conform to almost all checks, but for most checks there's a few proto files that don't. Of course I could fix everything (actually sometimes that's impossible, but okay), but that would involve a ton of work. The yaml solution is far from perfect as every time the config changes the whole repository needs to be re-linted rather than just one proto file that has changed. Not to mention a huge config with all the checks and files needs to be created and maintained. I would prefer to silence those places and create issues for maintainers to fix whatever is possible at their own pace. Instead I have to only enable a couple of very basic checks for the whole repo. Which means most of new bad code will not be rejected, so while existing issues are being fixed new ones will pop up.

As you can see, while principled, the no-comments approach is far from practical as it makes it impossible to implement buf check in a large repository in a meaningful way.

Is there a way to specify the HTTP client timeout when using a tarball served remotely over HTTP as an input? The current 5 second timeout is too short for us.

Currently im using protolock to verify protobuf backward compatibility, and it has a very useful command
protolock status -uptodate
that returns a non zero exit status in case the proto.lock is not up to date with all the .proto files in the project.
This integrates nicely with the CI flow, having the pipeline fail in case the user failed to update the image file in his sidebranch.

Having a similar feature in buf would allow me replace our current protolock usage with buf more easily.

protoc-gen-validate validation tag changes are not consider as breaking change. For instance

in master branch

string code = 1 [(validate.rules).string.min_len = 2]

in feature branch

string code = 1 [(validate.rules).string.min_len = 3]

expect buf should report has breaking changes but not. Any plan to include?

Hi, I have a monorepo structure for my project as below

├── my-service
│   ├── api
│   ├── buf.yaml
│   ├── cmd
│   └── pkg
├── common
│   ├── optisam
│   └── third_party
├── go.mod
└── go.sum

my buf.yaml

build:
  roots:
    - api/proto
    - ./../common/optisam/third_party/google

and I am getting error is outside the context directory. I checked this in code and there is a check on ... I am not sure why this check is imposed

See #21 and #14.

https://github.com/src-d/go-git seems to no longer be maintained, and going against the grain by using it has caused more problems than it has solved. While Buf aims to be self-contained and not shell out, git is a pretty widespread exception, including in the go binary itself.

One issue is temporary clones - for Buf usage in a long-running service - for example, a GitHub App that performs check runs (which we built internally), this could cause problems we need to make sure are handled (or just not do git operations in long-running services altogether for now).

By using buf to be able to run linting or break checking I have to import things like so: import "vendor/github.com/gogo/protobuf/gogoproto/gogo.proto"; is there a way to avoid having to use vendor

here is the buf.yaml file:

build:
  roots:
    - .
  excludes:
    - vendor/github.com/tendermint
lint:
  use:
    - DEFAULT
    - COMMENTS
    - FILE_LOWER_SNAKE_CASE
  except:
    - UNARY_RPC
    - COMMENT_FIELD
    - PACKAGE_DIRECTORY_MATCH
  ignore:
    - vendor
breaking:
  use:
    - FILE

In https://github.com/chef/automate, I've been wanting to buf ls-files.

Running buf ls-files without a config in the top-level of the checkout, it'll run into a context timeout. (If this isn't happening on a fresh checkout, it'll have something to do with various node_modules and similar folders popping up as one works on it...)

Trying to create a buf.yaml, I've started with

build:
  roots:
    - api
    - vendor/github.com/envoyproxy/protoc-gen-validate
    - vendor/github.com/grpc-ecosystem/grpc-gateway/third_party/googleapis

....but then I'm running into errors like these,

api/interservice/teams/teams.proto:5:8:api/api/external/common/version/version.proto: does not exist

because the import statements expect top-level as an import path. So, api/interservice/teams/teams.proto imports api/external/common/version/version.proto.

It's clear that rearranging the proto files' import paths to not start with api/ would fix the problem -- what I'm wondering about is if there's an easier way to fix this.

This is a great tool! Thanks.

I like the buf check breaking that tells you what exactly was broken (against a previous version).

However, would it be possible to add a buf check diff to tell exactly what have been changed (against a previous proto version)?

Before:

message Bar {
  enum Foo {
    FOO_UNSPECIFIED = 0;
    FOO_A = 1;
  }
  Foo field = 1;
}

After:

enum Foo {
  FOO_UNSPECIFIED = 0;
  FOO_A = 1;
}

message Bar {
  Foo field = 1;
}

This is currently detected as a breaking change with a message like:

Field "1" on message "Bar" changed type from "Bar.Foo" to "Foo".

This is not actually a breaking change in the wire format as the enum values are the same even if the type has changed name.

I am dealing with a set of proto files from a couple legacy repos that I cannot change. I can successfully build an image from these protos, but I cannot generate stubs from them with protoc. To generate stubs correctly I would have to write some nasty commands to automatically fixup the proto files before building the image. However, if I could build a JSON image, modify that really easily with jq, and then convert that to a binary image with buf to use as input to protoc, I wouldn't have to resort to hack-ily sed-ing the proto files. Is this possible?

P.S. Converting binary images to JSON would also be useful for introspection, but that is not necessary for me right now.

Hey Folks:
Got couple questions related to Schema Registry:

1. What's the timeline for releasing schema registry?
2. Is the buf schema registry going to be open sourced?
3. when talking about registry it mentioned that is a a publicly hosted and on-prem service. does it mean there's a chance to host it in house and not using the public service?

I am starting on building a new distributed system. I am determined to use gRPC with protobufs for all the good reasons. I have gone thru most of the documentation on https://buf.build/. The problem that I would like to solve for this new project upfront is to set up a proper artifact pipeline for the protobuf files to make it easy for other developers to create grpc services by providing them an easy way to import pre-generated and versioned proto client/server stubs. I ran into this medium article while looking for any preexisting solutions to solve that problem - https://medium.com/building-ibotta/building-a-scaleable-protocol-buffers-grpc-artifact-pipeline-5265c5118c9d

Is bufbuild/buf project aimed at solving this problem?

I'm slightly confused by the current wording about breaking checkers:

The default is FILE, which is our recommendation to guarantee maximum compatibility across your users. As opposed to linting, you generally will not mix and exclude specific breaking change checkers, instead choosing one of these options:

It seems like I shouldn't use multiple ones but yet implies that I might want to (you generally will not). Are all checkers a strict superset of the lower levels? I.e. does WIRE_JSON include all checks from FILE, PACKAGE, etc.?

To do this consistently across sources and image, extimage.ImageWithSpecificNames must handle whether imports are included or not. Then, the flag can be easily added.

I wanted to share a few thoughts on enums that may justify some minor tweaks to the style guide.

First of all, in your section on using FOO_BAR_UNSPECIFIED as the first value, the "Why?" page omits something extremely important, which is "why use FOO_BAR_UNSPECIFIED rather than just UNSPECIFIED"?

The reason: The C++ proto implementation causes all enum values to share the namespace of the enum, so...

enum Foo {
  UNSPECIFIED = 0;
}
enum Bar {
  UNSPECIFIED = 0; // Boom! These conflict.
}

This is unique to C++; it works fine in every other language.

This leads to one point in your style guide that I quibble with, which is the recommendation to avoid nesting enums. Because of this namespace issue, I have actually started recommending to my teams that they do nest enums, particularly State enums, when they can have reasonable confidence. In other words, I would much rather see...

message Foo {
  enum State {
    STATE_UNSPECIFIED = 0;
    ACTIVE = 1;
    RESTING = 2;
  }
  State state = 99;
}

...than the recommendation in the buf guide:

enum FooState {
  FOO_STATE_UNSPECIFIED = 0;
  ACTIVE = 1;
  RESTING = 2;
}
message Foo {
  FooState foo_state = 99;
}

Basically, the risk of accidental namespace collision feels (to me) greater than the concern that you might have to use a nested enum outside of its message later, particularly since Foo.State is okay in protobuf.

If nested enums are a no-no, then I would recommend prefixing every value with the enum name, not just the unspecified value:

enum FooState {
  FOO_STATE_UNSPECIFIED = 0;
  FOO_STATE_ACTIVE = 1;
  FOO_STATE_RESTING = 2;
}

However, then you are forcing that effect on users, which I feel is terrible. (Generally users are never typing the unspecified value), so on balance I think nesting enums is usually preferable provided that the enum really is a property of the enclosing message.

Just my two cents; up to your folks what your own style guide is. :-)

Description

In protobuf 3.12, optional was added back in. Buf should account for that and decide whether it's a breaking change or not.

What is currently being seen

field has label LABEL_OPTIONAL, but proto3 must omit labels other than 'repeated'

This project is looking great so far! Anything that can improve tooling in this area is sure to be beneficial.

Reading through the documentation, it is not immediately obvious what I should do with an image, outside of linting.

With respect to stub generation, it sounds like you folks plan to provide this as part of the registry service (woah!), but in the meantime it would be great to have some docs that detail how to use an image in this way.

Experimenting in a simple Go repo, I was able to generate stubs by running the following:

$ buf image build -o image.bin
$ protoc \
    --descriptor_set_in=image.bin \
    --go_out=plugins=grpc:. \
    $(buf ls-files | grep -v vendor)

Is this the intended/optimal way? It would be great to be able to integrate buf into a stub-generation pipeline in this capacity.

Cheers!

This means that changing the name of an enum value is reported as a wire-breaking change. Instead, comparisons should be done on number. We did name originally because due to allow_alias, names to tags are many to one, so the thinking was that name has to be the unique key for enum values. However, this doesn't allow people to rename enum values, which is desirable in a pure monorepo situation (for example, if people want to start abiding by ENUM_VALUE_PREFIX).

We need to:

• Add protodesc.NumberToEnumValues.
• Use protodesc.NumberToEnumValues instead of protodesc.NameToEnumValue in the ENUM_NO_DELETE.* checkers.
• Replace ENUM_VALUE_SAME_NUMBER with ENUM_VALUE_SAME_NAME.

In my repo where I've vendored in e.g. googleapis as a submodule, the command for comparing breaking against a git repo doesn't work. I suggest adding a new flag to the format ref for git that, when activated, will update init submodules recursively.

Expected

I expect the following to work for a repo with submodules:

buf check breaking --against-input '.git#branch=master'

Actual

It did not work, since the submodules will be empty after cloning, and therefore the breaking check will complain about missing imports (e.g. google/api/annotations.proto).

Suggestion

Add a submodule flag, e.g.:

 buf check breaking --against-input '.git#branch=master#submodules=true'

When the submodules flag is active, the breaking check will initialize submodules recursively in the (temporary) clone.

mkdir foo
cd foo
go mod init foo.bar
go get google.golang.org/protobuf/proto
go get github.com/bufbuild/buf/cmd/buf

The binary installed will drop any custom options defined in your proto files when generating the Image file.

I have the following Buf config. I am ignoring files in e2e but buf check lint still showing following errors

build:
  roots:
    - .
lint:
  use:
    - DEFAULT
    - FILE_LOWER_SNAKE_CASE
  except:
    - PACKAGE_DIRECTORY_MATCH
  ignore:
    - third_party
    - e2e
  ignore_only:
    RPC_RESPONSE_STANDARD_NAME:
      - srv/recorder/proto/transaction/transaction.proto
  rpc_allow_google_protobuf_empty_responses: true
breaking:
  use:
    - FILE
  ignore:
    - third_party
    - e2e

How to reproduce:

git clone https://github.com/xmlking/micro-starter-kit
buf check lint

Lint Error

buf check lint                              
srv/account/proto/profile/profile_service.proto:15:1:duplicate symbol micro.account.profile.v1.ProfileService: already defined as service in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:16:3:duplicate symbol micro.account.profile.v1.ProfileService.List: already defined as method in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:17:3:duplicate symbol micro.account.profile.v1.ProfileService.Get: already defined as method in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:18:3:duplicate symbol micro.account.profile.v1.ProfileService.Create: already defined as method in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:23:1:duplicate symbol micro.account.profile.v1.ListRequest: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:24:3:duplicate symbol micro.account.profile.v1.ListRequest.limit: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:30:3:duplicate symbol micro.account.profile.v1.ListRequest.page: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:31:3:duplicate symbol micro.account.profile.v1.ListRequest.sort: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:32:3:duplicate symbol micro.account.profile.v1.ListRequest.preferred_theme: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:42:3:duplicate symbol micro.account.profile.v1.ListRequest.gender: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:53:1:duplicate symbol micro.account.profile.v1.ListResponse: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:55:3:duplicate symbol micro.account.profile.v1.ListResponse.results: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:56:3:duplicate symbol micro.account.profile.v1.ListResponse.total: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:59:1:duplicate symbol micro.account.profile.v1.GetRequest: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:61:5:duplicate symbol micro.account.profile.v1.GetRequest.profile_id: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:62:5:duplicate symbol micro.account.profile.v1.GetRequest.user_id: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:66:1:duplicate symbol micro.account.profile.v1.GetResponse: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:68:3:duplicate symbol micro.account.profile.v1.GetResponse.result: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:71:1:duplicate symbol micro.account.profile.v1.CreateRequest: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:72:3:duplicate symbol micro.account.profile.v1.CreateRequest.user_id: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:73:3:duplicate symbol micro.account.profile.v1.CreateRequest.tz: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:74:3:duplicate symbol micro.account.profile.v1.CreateRequest.avatar: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:75:3:duplicate symbol micro.account.profile.v1.CreateRequest.gender: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:84:3:duplicate symbol micro.account.profile.v1.CreateRequest.birthday: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:85:3:duplicate symbol micro.account.profile.v1.CreateRequest.preferred_theme: already defined as field in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:97:1:duplicate symbol micro.account.profile.v1.CreateResponse: already defined as message in "e2e/profile_service.bloomrpc.proto"
srv/account/proto/profile/profile_service.proto:99:3:duplicate symbol micro.account.profile.v1.CreateResponse.result: already defined as field in "e2e/profile_service.bloomrpc.proto"

Ref : https://github.com/xmlking/micro-starter-kit/runs/435316698?check_suite_focus=true

since buf won’t allow referencing 3rd party proto files (proto gen validate, gorm etc) directly from outside the project , wonder if buf provide tooling to copy *.proto files from $GOPATH/src to project’s vendor directory?
here are some hacks i see from other developers
https://stepan.wtf/importing-protobuf-with-go-modules/

Can Buf also be used to show what's changed in proto files, not just the breaking changes?
Such as: new rpc, new fields, new messages etc?

https://buf.build/docs/migration-prototool

The above link href is https://buf.build/docs/github.com/uber/prototool which should be https://github.com/uber/prototool

I guess it's built without prefix [prototool](github.com/uber/prototool)

Hi, Is there any plans to support developers with vscode editor ?

Hi, I didnt find how I can create stubs from proto specifications. Is it provided currently or in the roadmap.

hello again 😄

I am running into an odd issue when a contributor pushes a pull request from their fork then the breakage checking can't find the master branch. you can see an example here: tendermint/tendermint#4461 & https://circleci.com/gh/tendermint/tendermint/96231?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

should I specify the github repo as well, not sure if this is documented.

Would love to easily be able to use a Buf-Docker container in e.g. CloudBuild.

Found a situation where buf image build generates a different binary image. It sometimes builds the same binary - seems like a race condition.

Example repo is here: https://github.com/sgtsquiggs/buf-example

If you are using a combination of gogoproto.wktpointer and gogoproto.moretags on the same value, the generated output is not deterministic.

Here's the offending proto file:

syntax = "proto3";

package billing;
option (gogoproto.goproto_registration) = true;

import "google/protobuf/wrappers.proto";
import "gogoproto/gogo.proto";

message ShortStockSchedule {
  message Request {
    google.protobuf.StringValue min_spread = 4 [(gogoproto.wktpointer) = true, (gogoproto.moretags) = 'validate:"omitempty,numeric"'];
  }
}

In the linked repo, if you run make test several times it will occasionally result in a diff

Hi,
I am going through buf documentation and I love and I wish to use it in my production code.

However, I have noticed that this is early days for buf and it is still under development.

Do you recommend buf to be used in production code as of this moment?

Searched for Python and Java in home page, and didn't find them. Can I use buf in a Java project/Python/etc? Or is that outside the purview of this project?

For example, https://github.com/toml-lang/toml/wiki contains a list of associated technologies that provide TOML support for multiple languages.

Hi,

I wanted to use protoc-gen-validate for specifying validation rules for my proto files. But when linting my files i am getting the following error:

my_file.proto:17:20:field id: unknown extension validate.rules

I have the protoc-gen-validate installed, but buf doesn't recognize this. Is it possible somewhere to configure this? Or to disable this check? Not sure which check is throwing this error.

Kind regards,
Daan

I was so happy to see a lengthy documentation on protobuf... So I thought "cool, I will finally replace prototool"... Got a glass of wine and tried the following... But, the basic "image" generation didn't work following the docs...

$ tree -L 1
.
├── README.md
├── buf.yaml
├── proto_modules
├── prototool.yaml
└── src

4 directories, 4 files

$ tree src/main/proto
src/main/proto
├── common
│   └── globalId.proto
├── course.proto
├── service.proto
└── student.proto

1 directory, 4 files

$ cat buf.yaml
build:
  roots:
    - src/main/proto
    - proto_modules/google-commons
    - proto_modules/protocol-buffers/src

$ docker run -ti -v $(pwd)/work -w /work bufbuild/buf ls-files
no input files found that match roots

What's next? I have protos under the proto_modules dir and src...

docker images | grep buf
bufbuild/buf                                                                            
latest              017f494f9c89 
       3 days ago          42.8MB