Large number of dependencies when instrumenting a library

[kyleconroy]

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.

[MrAlias]

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.

[kyleconroy]

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

[MrAlias]

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.

[MrAlias]

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

opentelemetry-go/go.mod

Lines 5 to 20 in aff7a80

	require (
	github.com/DataDog/sketches-go v0.0.0-20190923095040-43f19ad77ff7
	github.com/benbjohnson/clock v1.0.3
	github.com/davecgh/go-spew v1.1.1 // indirect
	github.com/golang/protobuf v1.4.2
	github.com/google/go-cmp v0.5.0
	github.com/google/gofuzz v1.0.0 // indirect
	github.com/kr/pretty v0.1.0 // indirect
	github.com/opentracing/opentracing-go v1.2.0
	github.com/stretchr/testify v1.6.1
	golang.org/x/net v0.0.0-20190613194153-d28f0bde5980 // indirect
	golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1 // indirect
	google.golang.org/genproto v0.0.0-20191009194640-548a555dbc03 // indirect
	google.golang.org/grpc v1.30.0
	gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 // indirect
	)

To 2:

opentelemetry-go/go.mod

Lines 5 to 8 in b7df554

	require (
	github.com/google/go-cmp v0.5.1
	github.com/stretchr/testify v1.6.1
	)

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.

[MrAlias]

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

[kyleconroy]

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