Hi all, I think this is related to https://github.com/golang/go/issues/26913 which is closed but still has commentary that seems unresolved after it was closed .
Scott On Friday, 28 September 2018 20:11:29 UTC+2, Harmen wrote: > > On Fri, Sep 28, 2018 at 10:19:50AM -0700, thepud...@gmail.com > <javascript:> wrote: > > Hi Harmen, > > > > And my first sentence might not have been clear. When I said "even in > your > > current situation, 'go build' is still pulling in exactly what it > needs", I > > was trying to reference the actual compilation process. > > > > In other words, I was just trying to make it clear that even if you have > > "extra" dependencies appearing in your go.mod file, the resulting binary > > produced by 'go build' does not have anything extra or any unused > > dependencies. > > Hi thepudds, > thanks for your anwers. > > It doesn't hurt per-se, but all those unused modules will be vendored in > the > repo (or the CI will have to download them every time). Maybe the consul > repo > is a particularly unlucky repo, since the /api package is small compared > to the > rest of the repo, but still. > > As for the argument that it's for test reproducibility, I do not follow > that. > Everything to test /api is there, and the stuff I don't import doesn't > need to > be tested in the first place. > > > In any event, I wanted to share at least my personal understanding, but > of > > course happy to learn more... > > I'm trying to do the same :) > Thanks! > > > > > --thepudds > > > > > > On Friday, September 28, 2018 at 1:00:17 PM UTC-4, thepud...@gmail.com > > wrote: > > > > > > > "So if consul adds a go.mod file in the root, then `mod tidy` will > > > suddenly > > > behave as I would expect (i.e. not pull in unused dependencies)? " > > > > > > Hi Harmen, > > > > > > Just in case this isn't already clear-- note that even in your current > > > situation, 'go build' is still pulling in exactly what it needs (and > not > > > pulling in unused dependencies). > > > > > > I think there is not a significant harm in your go.mod containing > these > > > indirect dependencies (aside from of course seeing that longer list, > etc.). > > > > > > And there is some benefit -- this behavior is part of what provides > for > > > 100% reproducible builds and tests. The modules system records precise > > > dependency version information, and in your case, that precise > dependency > > > version information for some of your indirect dependencies is being > > > recorded in your go.mod (given that it is not yet recorded in the > > > non-existent go.mod of some of your direct dependencies). > > > > > > As an example, this behavior helps make sure that `go test all` is > 100% > > > reproducible for you (where `go test all` runs tests for both your > module, > > > your direct dependencies, and your indirect dependencies, which is > valuable > > > as one way of validating that the currently selected packages versions > are > > > compatible -- the number of possible version combinations is > exponential in > > > the number of modules, so in general you cannot expect your > dependencies to > > > have tested against all possible combinations of *their* > dependencies). > > > > > > --thepudds > > > > > > On Friday, September 28, 2018 at 12:48:20 PM UTC-4, Harmen wrote: > > >> > > >> On Fri, Sep 28, 2018 at 04:48:32PM +0100, Paul Jolly wrote: > > >> > Hi Harmen > > >> > > > >> > I described the problem on > https://github.com/golang/go/issues/27920, > > >> which > > >> > > got > > >> > > closed within three minutes as being "documented", and "works as > > >> > > expected" (which I assume also means "works as intended"). > > >> > > Is this really the intented behaviour? It seems unexpected to me. > Or > > >> > > should I > > >> > > simply stay away from `go mod tidy`? > > >> > > > > >> > > > >> > I replied to your issue earlier. But could arguably have been > slightly > > >> more > > >> > detailed in my response beyond simply linking to > > >> > > > >> > https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-indirect-and-test-dependencies-in-my-gomod > > > >> > > > >> > As you note, github.com/hashicorp/consul/api is a package. It is a > > >> package > > >> > in the module github.com/hashicorp/consul. Despite there being no > > >> go.mod in > > >> > github.com/hashicorp/consul, the go tool simulates it as a module. > > >> > > > >> > Given there are no go.mod files in any subdirectories below > > >> > github.com/hashicorp/consul, then github.com/hashicorp/consul is > the > > >> module > > >> > for all the packages github.com/hashicorp/consul/... > > >> > > > >> > Hence go mod tidy (per the link in my response to your issue) is > > >> pulling > > >> > in the transitive dependencies needed for tests in > > >> > github.com/hashicorp/consul/... The reason you see all of these in > > >> your > > >> > go.mod is that github.com/hashicorp/consul has not yet been > converted > > >> to a > > >> > module as yet. > > >> > > > >> > Hopefully that gives a bit more colour on what's going on here. > > >> > > >> Hi Paul, > > >> > > >> thanks for your extended reply. > > >> > > >> So if consul adds a go.mod file in the root, then `mod tidy` will > > >> suddenly > > >> behave as I would expect (i.e. not pull in unused dependencies)? And > > >> until they > > >> add it (if ever) I either better not run `mod tidy`, or simply go > back to > > >> the > > >> old dep system? > > >> > > > > > > > -- > > 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...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- 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. For more options, visit https://groups.google.com/d/optout.
