TCN-787 complete type filtering on buf generate#1628
Conversation
jhump
left a comment
There was a problem hiding this comment.
Wow, short and sweet. Glad that ended up being so succinct.
|
This one is probably worth adding to the change log |
| "", | ||
| `The file or data to use for configuration.`, | ||
| ) | ||
| flagSet.StringSliceVar( |
There was a problem hiding this comment.
Is this what we want to do? We have plans to move more into the buf.gen.yaml into the future, this is going in the opposite direction. This feels like a major UI change
|
I love that this is so short. I'd imagined this being part of our managed mode configuration - is that crazy? |
|
@akshayjshah, @bufdev, so should this be completely not supported as command-line flag? Is there any precedent for things in the yaml being overridden via flag? If so, we could start this way and then add config to the yaml that can then be overridden via this flag. WDYT? |
|
@bufdev Going to bring your comment into this thread as i think its related.... That's a totally fair statement, shoving lists of types into the cli as flags will get messy under anything greater than very simple use. @akshayjshah Yes, I believe that is crazy. From my point of view, "Managed Mode" has 2 distinct characteristics:
Type filtering doesn't share these characteristics IMO. I believe they are more likely elevated to be equal seniority with version: v1
managed:
enabled: true
go_package_prefix:
default: github.com/bufbuild/buf/gen/proto/go
types:
- buf.alpha.module.v1alpha1.Module
plugins:
- plugin: go
out: gen/proto/go
opt: paths=source_relative |
This is reasonable, but hasn't been my impression. I think of "managed mode" as all the Buf features that are effectively editing the protobuf schemas on the fly, and this feels squarely in that category. Put differently, it's all the stuff that has no equivalent in As long as the type filters appear in the config somewhere though, I'm happy. |
jhump
left a comment
There was a problem hiding this comment.
Just one nit in flag doc. Otherwise LGTM
Adds `types` attribute to the `buf.gen.yaml`. The types (message, enum, service) that should be included in this image. When specified, the resulting image will only include descriptors to describe the requested types.
Adds
typesattribute to thebuf.gen.yaml:version: v1 plugins: - name: go out: gen/go + types: + include: + - "buf.alpha.lint.v1.IDPaths"and supply a
typesflag override to the cli:Usage: buf generate <input> [flags] Flags: --config string The file or data to use for configuration. --disable-symlinks Do not follow symlinks when reading sources or configuration from the local filesystem. By default, symlinks are followed in this CLI, but never followed on the Buf Schema Registry. --error-format string The format for build errors, printed to stderr. Must be one of [text,json,msvs,junit]. (default "text") --exclude-path strings Exclude specific files or directories, for example "proto/a/a.proto" or "proto/a". If specified multiple times, the union is taken. -h, --help help for generate --include-imports Also generate all imports except for Well-Known Types. --include-wkt Also generate Well-Known Types. Cannot be set without --include-imports. -o, --output string The base directory to generate to. This is prepended to the out directories in the generation template. (default ".") --path strings Limit to specific files or directories, for example "proto/a/a.proto" or "proto/a". If specified multiple times, the union is taken. --template string The generation template file or data to use. Must be in either YAML or JSON format. + --include-types strings The types (message, enum, service) that should be included in this image. When specified, the resulting image will only include descriptors to describe the requested types.resolves TCN-787
resolves TCN-788