Circular dependency with client_golang

[NightTsarina]

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.

[grobie]

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 notifications@github.com
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
.

[NightTsarina]

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?

[NightTsarina]

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

[beorn7]

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

[grobie]

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

[beorn7]

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?

[NightTsarina]

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.

[beorn7]

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.

[cornfeedhobo]

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