Allow restricting the output languages for given proto files

[Goldziher]

Hi,

So the issue I have is that I am using buf to generate clients and servers for multiple languages (4 and counting). I need some proto files to generate code only in go, others in a couple of languages, and others in all languages. There is not way for me to do this now using a single workspace, or am I missing something?

I would love to have some simple configuration (exclude / include, etc.) or an ability to next buf.gen files in sub folders rather than have these top level. As it stands now, I have to generate a large amount of completely useless code.

[Goldziher]

So, perhaps this can be done with exclude and include keywords. For example:

version: v1
managed:
    enabled: true
    optimize_for: LITE_RUNTIME
plugins:
    # typescript
    - plugin: buf.build/community/timostamm-protobuf-ts
      out: gen/ts
      exclude: [service1, service2]
    # golang
    - plugin: buf.build/grpc/go
      include: [service1]
      out: gen/go
      opt:
          - paths=source_relative
    - plugin: buf.build/protocolbuffers/go
      include: [service1]
      out: gen/go
      opt:
          - paths=source_relative
    # swift
    - plugin: buf.build/grpc/swift
      include: [service2]
      out: gen/swift
    - plugin: buf.build/apple/swift
      include: [service2]
      out: gen/swift

Note the addition of include / exclude.

[bufdev]

You can use seperate buf.gen.yamls via the buf generate --template flag, and you can also do separate buf generate calls that themselves use separate --path and --exclude-path values.

[Goldziher]

You can use seperate buf.gen.yamls via the buf generate --template flag, and you can also do separate buf generate calls that themselves use separate --path and --exclude-path values.

Thanks, but this pretty much defeats the purpose of having a tool like this. The moment using it becomes more cumbersum than using protoc directly, there is really no point for it.

[doriable]

We've made improvements to this in v2 of buf.gen.yaml, where you can define the inputs for each configuration file. You will still need to define a configuration file for each set/combination of desired plugins and inputs, e.g. buf.gen.foo.yaml, buf.gen.bar.yaml, and run with buf generate --template, but each configuration file should capture both the plugins and inputs without fiddling with command-line flags, only switching the --template.

Our guidance here would be to review our v2 docs linked above and migrate (migration guide from v1 to v2 is available here.

[doriable]

Given the provided guidance to migrate to v2, we are closing this as a duplicate of the feature request #3060.

[nmittler]

Thanks, but this pretty much defeats the purpose of having a tool like this. The moment using it becomes more cumbersum than using protoc directly, there is really no point for it.

I strongly agree with this statement. I have a somewhat similar issue over in #3060. My thought was that extending the module concept to include gen rules would help a lot. Not entirely sure if that addresses this one too ... maybe?