Hello fellow Gophers! I help maintain an SDK module <https://pkg.go.dev/github.com/getsentry/sentry-go> that includes packages that provide middleware to different web frameworks (e.g. echo <https://pkg.go.dev/github.com/getsentry/sentry-go@v0.12.0/echo>).
The SDK started out as a single module in a Git repository, and we have considered and hesitated splitting it into multiple modules <https://github.com/getsentry/sentry-go/issues/156> in a single repository because of the implications that it has on maintenance, development, testing and release processes. The root package implements the core functionality of the SDK and has no external dependencies, it only needs the standard library. That's what most people need. The other packages each depend on a web framework module, and downstream users typically only need to use one of those packages and do not want to bother about the others. The current `/go.mod` file is littered with dependencies to many web frameworks <https://github.com/getsentry/sentry-go/blob/6b72962bda2b1fb1ccc397b9d1aceb4f295606c5/go.mod> and their dependencies, and that has caused problems and confusion to our downstream users <https://github.com/getsentry/sentry-go/issues/376>, especially when one of those dependencies end up flagged by tools like Dependabot as containing a CVE. (Code security scanners seem to typically operate on the Go module level and not at the package level, so they often report problems even though the affected module/package is not part of the final build list of the main package.) I've been trying to find a way to eliminate the problems of the current single-module-per-repo setup while avoiding the implications of going multi-module-per-repo, as we have limited resources to maintain the SDK. The recent idea I had was to simply omit `require` entries in the `/go.mod` file <https://github.com/getsentry/sentry-go/issues/156#issuecomment-1012308188>, essentially making the module "untidy" (as in `go mod tidy` would re-introduce the missing requires), but I haven't found any mention to that approach on the Internet. That idea seems hacky and possibly not conforming to the spec, but perhaps not totally invalid. As I read https://go.dev/ref/mod#go-mod-file and https://go.dev/ref/mod#go-mod-file-updates, I understand that the important `go.mod` file is the one of the main module (i.e. the `go.mod` file of our downstream users), and as long as the main module requires the same web framework as expected by the SDK middleware (when used), the Go tool should be able to determine versions and complete the build. I'd like to hear thoughts from others -- has anyone tried something similar? Should I expect obvious problems for downstream consumers, like failed builds? Is there an alternative solution to be considered? Thanks, Rodolfo Carvalho PS: the module graph pruning <https://github.com/golang/go/issues/36460> from Go 1.17 <https://go.dev/doc/go1.17#go-command> has been of great help addressing another problem of the single-module-per-repo setup, making it such that our users that are on Go 1.17 do not need to download go.mod files from modules they don't depend on. Many thanks to Bryan C. Mills and the rest of the Go team! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANkx08i8%2BrsprcPU5Tv7Qsg2MLx%3DV-XV%2Be5kokSQStyyP8WH%2BQ%40mail.gmail.com.
