Why so many go.mod files (Go modules) in this repo?

[srabraham]

Hi there,
I see that this repo has a lot of Go modules (31, by current count). What's the reasoning behind this? Many of those modules make extensive reference to other Go modules in the repo, using dependency replacement (e.g. replace go.opentelemetry.io/otel/metric => ../../../../metric).

I think I'd understand if there were multiple fairly separate code packages in the repo, but many/most of your clients need to import 5+ of these modules to do basic stuff. e.g. if I want to export metrics over gRPC, then in addition to core stuff, I'll minimally need the modules defined by opentelemetry-go/exporters/otlp/otlpmetric/go.mod and its subdirectory opentelemetry-go/exporters/otlp/otlpmetric/otlpmetricgrpc/go.mod. The subdir otlpmetricgrpc module depends upon the parent dir through a replace. (I also notice that those two modules have different external dependency versions, e.g. each wants a different version of google.golang.org/grpc.)

All I can figure about this modularization is that it's about limiting clients' need to bring in unnecessary transitive dependencies, but it feels like this might be going a bit too far. It might be easier to work with this project if it had fewer modules. I'm curious for an engineer's elaboration on why things are as they are. Thanks!

(please change the issue label to "question". GitHub isn't letting me set that label myself)

[pellared]

I think it is an excellent question as Go 1.17 (and Go 1.18 is the minimum supported version) has added https://go.dev/ref/mod#graph-pruning. Therefore the unnecessary transitive dependencies should not be a big deal.