Circular dependency with client_golang about common HOT 10 CLOSED

Relevant discussion is happening here: https://cloud-native.slack.com/archives/C01AUBA4PFE/p1704099677796159

from common.

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?

from common.

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?

from common.

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.

from common.

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
#58, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAANaEmM3F66e1l56H5kKpNZMoHllh5oks5qowKsgaJpZM4J5zWQ
.

from common.

Please note that I would really like not to do this hack, as it is also a lot more trouble for me..

from common.

from common.

@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.

from common.

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.

from common.

I just want to be clear, the proposed workaround does not scale or even work for enterprise environments. Please reconsider looking into this.

from common.