Go's dependency resolution doesn't work at that fine-grained of a level, it works on the module (unit of versioning) graph, not the package import graph. If your library is imported and used, all the dependency versions in your `go.mod` participate in version selection. This could present a problem if your tools introduce a version higher than what your consumer would otherwise have selected.
On Monday, January 24, 2022 at 10:45:29 PM UTC+1 sv...@redhat.com wrote: > Hi Sean, > > Thanks a lot for your answer! > > On Mon, Jan 24, 2022 at 9:01 PM Sean Liao <seank...@gmail.com> wrote: > >> As a (hypothetical) consumer of your library, I would definitely >> appreciate fewer dependencies, >> mostly to reduce the chance of (or difficulty of resolving) conflicts >> with any other dependencies I may have >> (especially painful when incompatible v0.X.Y transitive dependencies are >> used). >> > > Are conflicts really possible? Let's call the dependency of our internal > tool "foo". So, if I'm not mistaken, conflicts could not appear, because as > a user of our library the Go tooling would only follow the import graph, > and because our library is not using "foo" (only our helper tool is) it > would never evaluate our go.mod entry for "foo". If your own code has > another dependency that is using "foo", it would only evaluate the go.mod > file of _that_ dependency, and there is no conflict possible. Am I getting > this wrong? > > -- 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/cf7802e6-5b9c-4938-ad42-cedb634cd97fn%40googlegroups.com.
