Generated code does not compile

[tzachshabtay]

Hi, I'm trying to generate code for the buf schema registry protobufs.

It generates the code but getting 2 compiler errors:

error[E0433]: failed to resolve: could not find `compiler` in `pbjson_types`
   --> src/gen/buf.alpha.registry.v1alpha1.rs:555:61
    |
555 |     pub responses: ::prost::alloc::vec::Vec<::pbjson_types::compiler::CodeGeneratorResponse>,
    |                                                             ^^^^^^^^ could not find `compiler` in `pbjson_types`

error[E0283]: type annotations needed
   --> src/gen/buf.alpha.registry.v1alpha1.rs:550:28
    |
550 | #[derive(Clone, PartialEq, ::prost::Message)]
    |                            ^^^^^^^^^^^^^^^^ cannot infer type
    |
    = note: cannot satisfy `_: std::default::Default`
    = note: this error originates in the derive macro `::prost::Message` (in Nightly builds, run with -Z macro-backtrace for more info)

The generated code for this section looks like this:

#[derive(Clone, PartialEq, ::prost::Message)]
pub struct GeneratePluginsResponse {
    /// Contains all the responses from the generated plugins. The order
    /// is defined by the order of the plugins in the request.
    #[prost(message, repeated, tag="1")]
    pub responses: ::prost::alloc::vec::Vec<::pbjson_types::compiler::CodeGeneratorResponse>,
    /// An optional array defining runtime libraries that the generated code
    /// requires to run, as specified by the plugin author. This may contain
    /// duplicate entries as the generation can be the result of multiple plugins,
    /// each of which declares its own runtime library dependencies. The libraries
    /// returned are lexicographically ordered by their name, but not deduplicated.
    /// How to handle duplicate libraries is left to the user.
    #[prost(message, repeated, tag="2")]
    pub runtime_libraries: ::prost::alloc::vec::Vec<RuntimeLibrary>,
}

My buf.gen.yaml:

version: v1
plugins:
  - remote: buf.build/prost/plugins/prost:v0.2.1-1
    out: src/gen
    opt:
      - bytes=.
      - compile_well_known_types
      - extern_path=.google.protobuf=::pbjson_types
      - file_descriptor_set
  - remote: buf.build/prost/plugins/serde:v0.2.1-1
    out: src/gen
  - remote: buf.build/prost/plugins/tonic:v0.2.1-1
    out: src/gen
    opt:
      - compile_well_known_types
      - extern_path=.google.protobuf=::pbjson_types
  - remote: buf.build/prost/plugins/crate:v0.3.1-1
    out: src/gen
    opt:
      - no_features

And running it via buf generate buf.build/bufbuild/buf:68da9dcf7ad819b7725e798deaf9ced5fe782e0f

My cargo.toml dependencies:

bytes = "1.1.0"
prost = "0.11.0"
pbjson = "0.5"
pbjson-types = "0.5.1"
serde = "1.0"
tonic = { version = "0.8", features = ["gzip"] }

I don't know if this is a bug or if I'm doing something wrong?

[neoeinstein]

This may just be a mismatch with what the pbjson-types crate is actually providing. The compiler package is a part of the Google Protobuf Well-Known Types, but it looks like pbjson-types is not providing the code for those types (note the lack of a compiler module). If you don't strictly need Serde serialization/deserialization for those types, you may consider just using the compiler type definitions provided in prost-types. You may also be able to compile your own duplicates of the well known types, and then use an extern_paths directive to indicate that .google.protobuf.compiler should resolve to your own definitions. It's not a purely straightforward answer, unfortunately.

I might also encourage you to stop by the influxdb/pbjson repository and look to see if there's an issue requesting that the compiler package be added to their generated -types crate, or file one yourself if not.

[tzachshabtay]

Thanks, I filed a ticket for influxdb/pbjson.

Currently I think I can live without those types, how do I tell the code-gen to use the compiler type definitions provided in prost-types? Or alterntively, how do I tell the code-gen to completely skip generating the code for the GeneratePlugins rpc with its request and response types?

Thanks.