> "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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
