On 22.12.22 21:01, Shengjing Zhu wrote:
On Thu, Dec 22, 2022 at 07:54:49AM +, 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 depende
On Thu, Dec 22, 2022 at 07:54:49AM +, Peymaneh wrote:
> Hi
>
> Am 22. Dezember 2022 08:00:36 MEZ schrieb Daniel Swarbrick
> :
> >Hi,
> >
> >On 22.12.22 16:30, Shengjing Zhu wrote:
> >
> >> So I think we can follow upstream, which means:
> >>
> >> + still uses protoc-gen-go 1.3 to regenerate
Hi
Am 22. Dezember 2022 08:00:36 MEZ schrieb Daniel Swarbrick
:
>Hi,
>
>On 22.12.22 16:30, Shengjing Zhu wrote:
>
>> So I think we can follow upstream, which means:
>>
>> + still uses protoc-gen-go 1.3 to regenerate the client_model, ensure it only
>>imports github.com/golang/protobuf. This
Hi,
On 22.12.22 16:30, Shengjing Zhu wrote:
So I think we can follow upstream, which means:
+ still uses protoc-gen-go 1.3 to regenerate the client_model, ensure it only
imports github.com/golang/protobuf. This is to make sure other packages that
still depend on old protobuf won't break.
On Thu, Dec 22, 2022 at 01:31:17PM +1300, Daniel Swarbrick wrote:
> Hi,
>
> I'm throwing this out to the team in hope of getting some help with a tricky
> problem regarding two packages central to the Prometheus ecosystem.
>
> golang-github-prometheus-common and golang-github-prometheus-client-go
Hi,
I'm throwing this out to the team in hope of getting some help with a
tricky problem regarding two packages central to the Prometheus ecosystem.
golang-github-prometheus-common and
golang-github-prometheus-client-golang have a circular dependency on
each other. They have also both long d
