Google-cloud-go: cloud.google.com/go should not reference github.com/census-instrumentation/opencensus-go

[nim-nim]

cloud.google.com/go is a core Go package for google apis, grpc and golang/x/auth

It's a low-level Go package used indirectly by many other Go packages

It should not reference reference go.opencensus.io that references high-level Go packages such as Prometheus, as that makes bootstraping a clean Go environment, where every package is unit tested before inclusion in the baseline, impossible.

[jba]

/cc @rakyll

I think there's a confusion here between "package" and "repo". No package under cloud.google.com/go should depend on the package go.opencensus.io/exporter/prometheus. Some depend on other packages in the same repo. Do any of those go.opencensus.io packages depend on prometheus? They shouldn't.

If you follow just the package dependency tree, and not that of the repos, you should be able to do what you're trying to do.

[nim-nim]

@jba

That's a developer view

When you take the integrator role you don't integrate repositories piecemeal you integrate them as a whole. Some repositories are giants it would be madness to try to check them subdirectory by subdirectory, especially when the ordering would depend on all the third-party subdirectories they use or are used by.

So you do each repository as a whole and importing any part go.opencensus.io pulls in lots of high-level code like prometheus

(the incestuous relationship between golang/x/auth cloud.google.com and google.golang.org/api is already quite a PITA to manage but it's nothing compared to what go.opencensus.io pulls in)

Integrators are like everyone else, they want a nice directed acyclic graph or repositories to check and integrate, that's the only configuration that allows computing check order (of course you can punt on ordering and integration checks and just copy repositories in a giant vendored lump without running any unit test, that's a good way to ship broken code).

It's a pity that go.opencensus.io did not split its code between a small core repo others can reference, and an external connectors repo, but in the meanwhile that makes integration of new cloud.google.com versions a lot more difficult than should be and a core Go repository should be more careful of such side effects.

[rakyll]

We are currently splitting exporters to their own repos. Sorry, we have never considered to keep everything together forever and was waiting for all API improvements to be finished before splitting them but there is quite a high interest to add more backend support (which was something we were not expecting this soon) and hence we are doing it right now.

/cc @ramonza

[jba]

@rakyll, how is the repo splitting going?

[rakyll]

We are moving out the vendor-specific exporters to https://github.com/census-ecosystem.

AWS, Google and Datadog support lives out of the core. We are waiting for our users to migrate and will merge https://github.com/census-instrumentation/opencensus-go/pull/790 to finally remove the Stackdriver support as well.

Zipkin, Prometheus and Jeager exporters are going to live in the core repo but the good news is that they are very tiny libraries. And if you don't depend on them to register an exporter, their dependencies won't be fetched.

[jadekler]

https://github.com/census-instrumentation/opencensus-go/pull/790 is now finished. Can we close this issue? I don't think we'll ever stop being able to depend on go.opencensus.io, but with exporters in their own repos I expect this becomes less of a problem.

[jadekler]

Nevermind, the commit is being reverted. My comment stands... after we fix and get that commit back in. :)

[jadekler]

I'm going to call this done and close the issue, unless anyone has objections. As @rakyll mentioned, several vendor-specific exporters have been moved already. Also, https://code-review.googlesource.com/c/google-api-go-client/+/32351 should help the issue. Beyond that, unfortunately never be completely independent of opencensus.