hundreds-father-40404/22/2022, 11:06 PM
# TODO: Consider how to merge this code with existing dependency inference code.We need the dependencies on the generated targets to show up for project introspection to work: e.g.
fast-nail-5540004/22/2022, 11:07 PM
hundreds-father-40404/22/2022, 11:09 PM
which could maybe be inferred from protobuf_source deps but easier to just run analysis.Okay. From a correctness standpoint, it's probably better that we do use the protobuf dependencies. For example, we have protobuf dependency inference
There is no definitive list for the packages except in the generated sources.For python, we hardcode looking for the owner of
. It has worked well Given that we directly run Protoc, could we hardcode the list? We can look at the GRPC field to know if that needs to be inferred
This module (github.com/golang/protobuf) contains Go bindings for protocol buffers.
It has been superseded by the google.golang.org/protobuf module, which contains an updated and simplified API, support for protobuf reflection, and many other improvements. We recommend that new code use the google.golang.org/protobuf module.
witty-crayon-2278604/22/2022, 11:39 PM
hundreds-father-40404/22/2022, 11:39 PM
, I think 1 might not be true anymore? i.e. it's safe to hardcode If users are somehow generating a old version that uses the order dependencies, they can always manually add the dependencies
is to avoid needing to run codegen in order to compute dependenciesAgreed. And for now, we work around it by not integrating into the dependency system