I considered this but I intend to donate it to the OpenTelemetry project (at the request of a member of the governance committee, and I like that idea for several reasons) and they seem to prefer the monorepo approach whenever possible.
I’ve gone down this road, too. Sharing a dependency tree among all of the libraries is unfortunately a non-starter. An app that depends on a library that instruments itself with OpenTelemetry (as recommended by OTel) would then depend on everything the SDK depends on, all the way down to Protobufs for OTLP, not even counting other exporters yet. This is true even if they aren’t using OTel — the API should have no dependencies at all specifically for this scenario. This has the potential to block dependency updates when there are version mismatches downstream, which would be a huge source of friction.
One solution to this is to maintain instrumentation shards separately so the application would need to opt into that dependency. However, that puts a maintenance burden on the maintainers of an instrumentation shard (keep an eye on each release, figure out a support matrix for each version, etc) as well as developers of applications using them (the feature shards and the instrumentation shards may need to be updated in lockstep, but not always and it’s up to you to figure it out).
The other solution is the monorepo, which is why I was asking about it. It wouldn’t solve all the things (for example, instrumentation shards may still need to exist for shards that won’t accept
opentelemetry-api as a dependency or for stdlib code like
HTTP::Client) but it would definitely mitigate the sum of them, which may very well be why the OpenTelemetry project prefers monorepos.
Stephanie makes a really good point here. Using git repos rather than a centralized package repository where you can submit snapshots of select files makes this really, really difficult.
shards is based off of Go’s dep management, I’ll look into how the OTel Go libraries are distributed and see if I can get some insights there, but I think Go imports let you drill down into the directory structure of the git repo.
I have a feeling it’s gonna end up fanned out across a lot of different repos, unfortunately.