hundreds-father-404
04/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.
dependees
and --changed-since
.fast-nail-55400
04/22/2022, 11:07 PMhundreds-father-404
04/22/2022, 11:09 PMwhich 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
google.protobuf
. 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<http://github.com/golang/protobuf|github.com/golang/protobuf>
, <http://google.golang.org/genproto|google.golang.org/genproto>
, and <http://google.golang.org/protobuf|google.golang.org/protobuf>
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-22786
04/22/2022, 11:39 PMhundreds-father-404
04/22/2022, 11:39 PM<http://google.golang.org/protobuf|google.golang.org/protobuf>
, 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 dependenciesis 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