common
common copied to clipboard
prometheus
Circular dependency with client_golang
Hey,
I just got reported (I had not noticed), that there is a circular dependency between common and client_golang, which is pretty problematic for transitions, backports, etc.
In the file version/info.go, the client library is imported to create metrics with version information. Is there any sane way to break this cycle? Otherwise, I guess I should just merge the packages; they can't be used independently anyway.
In Golang dependencies are defined on a package level, and not on repository level. Circular dependencies are forbidden and impossible in golang, but with a catch-all common repository I think you'll continue to run into such issues.
On Sat, Sep 10, 2016 at 3:19 PM Martín Ferrari [email protected] wrote:
Hey,
I just got reported (I had not noticed), that there is a circular dependency between common and client_golang, which is pretty problematic for transitions, backports, etc.
In the file version/info.go, the client library is imported to create metrics with version information. Is there any sane way to break this cycle? Otherwise, I guess I should just merge the packages; they can't be used independently anyway.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prometheus/common/issues/58, or mute the thread https://github.com/notifications/unsubscribe-auth/AAANaEmM3F66e1l56H5kKpNZMoHllh5oks5qowKsgaJpZM4J5zWQ .
Grobie,
Yes, this is circular only in the repository sense, which is the one I care about :-)
Now, this is not a critical bug, but it means more pain for users and release managers, with no real benefit, so I would like to fix it. Why do you say that after merging client_golang and common I will keep encountering these problems?
Please note that I would really like not to do this hack, as it is also a lot more trouble for me..
common is a bag of commonly used packages. Previously, some of it
was part of client_golang, which was back then an even bigger bag
with a misleading name on top. (Now it is essentially two packages,
the exposition library and the API client.)
Avoiding circular dependencies on the repository level will be hard.
In terms of deb packaging, I'd suggest to either do the more detailed
approach and mirror the Go packages in common (and perhaps partially
client_golang), i.e. let Go enforce that there will be no circular
dependencies. Or you become coarser and put client_golang and
common all into one deb package.
@TheTincho I meant that without mirroring the go package structure you'll continue to run into such problems with the current common repository. I'm not sure merging common into client_golang is something we want to do, the packages are also used without client_golang.
I don't really see us addressing this issue and I'm tempted to close it as "not feasible". @TheTincho how are you dealing with this at the moment?
At the moment, I am able to work around this by excluding common/version from build and tests, and then adding it manually to the package. This way, at least I don't get a circular build dependency (which would give all kinds of headache for bootstrapping, backporting, etc), but the resulting packages still have the circular dep.
So, it is not ideal, but not as bad.
OK, thanks. I'll close this then because realistically, I don't see us changing the repo structure, given that a workaround for Debian is in place.
I just want to be clear, the proposed workaround does not scale or even work for enterprise environments. Please reconsider looking into this.
Relevant discussion is happening here: https://cloud-native.slack.com/archives/C01AUBA4PFE/p1704099677796159
Circular dependency has been solved after moving the version collector to client_golang!
https://github.com/prometheus/common/pull/579 https://github.com/prometheus/common/pull/591 https://github.com/prometheus/client_golang/pull/1422
