Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APIv2: naming of packages under types #849

dsnet opened this issue May 13, 2019 · 2 comments


None yet
2 participants
Copy link

commented May 13, 2019

Related to #848, but broken out to avoid cluttering the discussion there.

Currently, we have the following packages (package path and name):

  • types/descriptor with package descriptor_proto
  • types/known with package known_proto
  • types/plugin with package plugin_proto

Currently, this:

  • Violates the general principle where path.Base(packagePath) == packageName
  • Registers all of the well-known types, so long as one of them is used. This is contrary to the behavior in other languages.

Ideally, our generated protos should:

  • Not violate conventional package path/name style
  • Avoid registering all well-known types together
  • Have a consistent naming style for all package names. If we break up the well-known types, the struct.proto and type.proto have a naming conflict with keywords in Go if we trivially use the .proto file name for the Go package name.

As such, I propose the following layout:

  • types/descriptorpb
  • types/known/anypb
  • types/known/apipb
  • types/known/durationpb
  • types/known/emptypb
  • types/known/fieldmaskpb
  • types/known/sourcecontextpb
  • types/known/structpb
  • types/known/timestamppb
  • types/known/typepb
  • types/known/wrapperspb
  • types/pluginpb

The package name is the base of the package path. The name is derived from the .proto file name by replacing the .proto with pb and removing all underscores (e.g., source_context.proto -> sourcecontextbp).

Alternatively, we could replace .proto with _proto (e.g., source_context.proto -> source_context_proto). Since the name is long, people would be expected to rename the import as they likely do today already.

\cc @neild, @cybrcodr

@dsnet dsnet added the api-v2 label May 13, 2019


This comment has been minimized.

Copy link

commented May 14, 2019

I like the proposal. Breaking up the well-known types into separate Go packages is a good thing.


This comment has been minimized.

Copy link
Member Author

commented May 16, 2019

@dsnet dsnet closed this May 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.