I'm a user of the sentry-go SDK who has been impacted by the large number of dependencies in the past.
>Independently, if your users have automated tools that are issuing false-positive CVE warnings based on the module graph instead of the package-import graph, you may want to suggest that they file issues against those tools. Does using the package-import graph capture the full picture of how a module impacts importers of the module. My understanding – maybe incorrect or out-dated – is that importing a module still brings that modules complete dependency graph into the dependency resolution process. Anyone using dependencies imported will be limited by the minimum versions defined in sentry-go SDK or any transitive dependency through sentry-go. Even if their go.mod is simpler on the surface, an SDK with a large and far reaching dependency graph can still impact other projects. Bryan, is there a good example of how to use the go tool to provide details of the package-import graph? I would normally use go mod graph and go mod why which as I understand both are limited to the module graph. Thanks! Leigh On Friday, January 21, 2022 at 1:31:12 PM UTC-8 Bryan C. Mills wrote: > On Thursday, January 13, 2022 at 12:45:13 PM UTC-5 rhcar...@gmail.com > wrote: > >> 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.) >> > > As you noted, this is one of the use-cases we had in mind for module graph > pruning in Go 1.17. > So one option is to run 'go mod tidy -go=1.17' to upgrade your module to > support pruning, so that the consumers of your module won't themselves need > to download irrelevant dependencies. That shouldn't harm any of your users > on older Go versions (we designed it to be backward-compatible), although > they won't see the benefits of pruning until they upgrade. > > Independently, if your users have automated tools that are issuing > false-positive CVE warnings based on the module graph instead of the > package-import graph, you may want to suggest that they file issues against > those tools. Ideally automated tools ought to be using the package-import > graph instead of the module graph; however, if that's too involved they > could still get a better approximation by consulting the `go.sum` file for > the main module. (Modules that contribute packages relevant to the build > will have source-code checksums in the `go.sum` file; modules that are in > the module graph but not otherwise relevant will have only `/go.mod` > checksums.) > > > 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. >> > > We have tests of cmd/go behavior in that kind of configuration, but we > don't recommend it. Leaving your module untidy makes builds of your > packages less reproducible for users, and in some cases can also cause > extra work for the `go` command to resolve the latest versions of those > dependencies. If you leave dependencies out of your own `go.mod` file, then > those dependencies will be resolved and added to your users' `go.mod` files > when they run `go mod tidy` — but they are resolved to the latest release > of each missing dependency, which means a bit more latency to identify what > the latest release is, and an increased risk of breakage from incompatible > changes in those dependencies. > > We designed module graph pruning specifically to address use-cases like > yours, so I would suggest leaning on that feature — and please do file > issues (or feel free to shoot me an email!) if you run into bugs or rough > edges. > > > 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/cd30f96c-fc26-4de1-8034-5474916e9560n%40googlegroups.com.
