Opentelemetry-go: Large number of dependencies when instrumenting a library

Created on 15 Jul 2020  路  6Comments  路  Source: open-telemetry/opentelemetry-go

First off, thanks for all the hard work on OpenTelemetry.

I recently ran into an issue with the go-redis package. Adding it to a new project pulled in a large set of dependencies, including google.golang.org/grpc and cloud.google.com/go. It turns out this is because the go-redis package imports go.opentelemetry.io/otel. This situation is addressed in the README

Libraries that produce telemetry data should only depend on api and defer the choice of the SDK to the application developer. Applications may depend on sdk or another package that implements the API.

However, a library can't only depend on the api package. When using Go modules, the entire go.opentelemetry.io/otel module is required. How feasible would it be to split the api and sdk packages into separate modules? This way, the api module could have a much smaller set of dependent packages, hopefully excluding google.golang.org/grpc.

question required-for-ga

Most helpful comment

This seems like a reasonable ask to me. I'm going to add it to the SIG agenda to talk about tomorrow. I'll update with details of the discussion.

All 6 comments

This seems like a reasonable ask to me. I'm going to add it to the SIG agenda to talk about tomorrow. I'll update with details of the discussion.

Thanks! Let me know what I can do to help. Happy to write up a larger explanation of my issue.

Looking into this the status code for the Span in the trace API uses google.golang.org/grpc/codes bringing the import into the API. We need to look at alternatives to avoid this.

We've gone from 14 direct (external) dependencies:

https://github.com/open-telemetry/opentelemetry-go/blob/aff7a80d5a463bea1d1d310e4e1e119703f80dd0/go.mod#L5-L20

To 2:

https://github.com/open-telemetry/opentelemetry-go/blob/b7df5543e398789ae2f9ae75c0868a92a55d7fe0/go.mod#L5-L8

With these last two being testing dependencies. I feel like we could in the future build out the testing to only rely on the testing package, but it might be diminishing returns to try here (likely just going to be reproducing imported functionality).

I'm going to close this at this point with all the reduction that we have achieved and if we want to tackle the last two a new issue can be opened to address them.

Still need to do a release to get these savings published.

@MrAlias Wow! This is fantastic.

It took me about 10 minutes to open up the issue, but it obviously took far more work for the team to fix it. Thank you (and everyone else) for closing this out. I agree that testify and go-cmp are fine.

Thanks again!

Was this page helpful?
0 / 5 - 0 ratings