On 22.12.22 21:01, Shengjing Zhu wrote:
On Thu, Dec 22, 2022 at 07:54:49AM +0000, Peymaneh wrote:Maybe it is an option to vendor one of the prometheus packages in the other respective package to get rid of the build dependency, and drop the vendored files and reintroduce the circular dependency in a later revision once they do not depend on go protobuf 1-3?I'm very concerned about such _vendor_ advise without investigation the situation first. Upstream has the opinion that client_model is using protobuf v1, since they haven't decided how the breaking changes would impact.
Vendoring client_golang in prometheus-common might be an option, since it is only imported in one place.
However, that still won't resolve the conflict between protobuf-1-3 (B-D in prometheus-client-model) and protobuf-1.5 if swapped out in prometheus-common & prometheus-client-golang.
The protobuf-1.3 B-D in prometheus-client-model can be updated to protobuf-1-5 without having any breaking effect on the regenerated metrics.pb.go. However, any downstream packages which B-D on prometheus-client-model _and_ protobuf-1-3 are going to experience a conflict. Another chicken-egg problem.