Hi thepudds, Thx for your support and the link of issue. Are you asking how to just upgrade your direct dependencies (and then your indirect dependencies are upgraded according to the various 'require' statements in the various 'go.mod' files)? Yes.
If so, could you say a bit more about why you are interested in doing that? >From my point of view, I don't want manage the indirect dependencies because I can't assumed that the combination of direct dependency with newer indirect dependency works. Only the maintainer has to assume this. And I prefer to create issue to maintainer of my direct dependency in order to tell him a newer version of indirect dependency has been released with fix. He will be in charge of to upgrade his direct dependency and check everything works correctly. In the case of the upgrade has to be done, and we can't waiting for upgrade of maintainer (because the maintainer is off), go get -u github.com/someone/mydirectdepency/ is great to overrull the go.mod of my direct dependency. Best Jerome Le dimanche 4 novembre 2018 13:44:57 UTC+1, thepud...@gmail.com a écrit : > > Hi Jerome, > > Are you asking how to just upgrade your direct dependencies (and then your > indirect dependencies are upgraded according to the various 'require' > statements in the various 'go.mod' files)? > > If so, could you say a bit more about why you are interested in doing that? > > Also, you might be interested in this suggestion to make it easier to just > upgrade your direct dependencies: > > #28424 - cmd/go: consider easier separation of upgrades to direct vs. > indirect dependencies, including to help with 'high-fidelity builds' > https://github.com/golang/go/issues/28424 > > In terms of what can be done today, it might not feel completely natural, > but I think the following does what you are asking about (conceptually `go > get direct@latest`, if that was supported): > > # Dry run: list your direct dependencies: > go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' > > # Upgrade your direct dependencies to their latest release > go get $(go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' > -m all)``` > > In general, it seems upgrading direct dependencies has a different risk > profile than upgrading indirect dependencies, including because people > usually have more familiarity with their direct dependencies than possibly > deeply nested indirect dependencies. > > Especially compared to doing a simple 'go get -u' or 'go get -u=patch', > making it easier to just upgrade direct dependencies would I think allow > people to more easily retain more benefits of the module system's > philosophy of 'High-Fidelity Builds' (by at least having the option to more > easily apply that philosophy during an upgrade). > > In any event, I'd be curious to hear more about your use case... > > Best, > thepudds > > On Sunday, November 4, 2018 at 4:32:06 AM UTC-5, Jérôme LAFORGE wrote: >> >> Hello all, >> I am looking for a way to upgrade all none transitive modules (and >> eventually upgrade transitive modules according to go.mod from upgraded >> none transitive modules). >> >> Beause go get -u, upgrade all modules (transitive and none transitive >> modules). >> >> Thx in adv >> Jerome >> > -- 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.