all: update dependencies #1155
all: update dependencies #1155
Conversation
|
@bcmills Consider this a friction report for module-mode |
|
|
Can you give some more detail on the “etc.d madness”? |
|
Sure. When I deleted everything in There were also errors like this: Through trial and error of manually doing "go get" of the previous versions of various More recently I was able to update to the latest of |
|
One question: when you say you want to run If you are interested in (a), as you have seen, that can present some challenges, especially given this is a transitional time period. If we take the example of If you are instead interested in (b), one approach you can use is to bootstrap your versions to get a consistent set of recent Sorry if that is not a great explanation, but the following FAQ covers the technique in a bit more detail: And here is a concrete example in golang/go#28489 (comment) of following that technique (for docker, in that example). |
If you delete everything in In contrast, Perhaps what you wanted instead was |
Things likely could have been smoother here if edit: part of the reason I say that is because the technique described in the FAQ two comments back #1155 (comment) would not be useful if there was a |
|
I want to run |
|
To upgrade just your direct dependencies to their latest release, you can do:
```
go get $(go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' -m all)
```
Note there is no `-u`.
A little more discussion here, including the suggestion to make that easier:
golang/go#28424
So you could rewind to your previously working `go.mod ` file that you previously shipped, and just upgrade your direct dependencies.
If you then see a problem, you could pick your 1-2 most problematic direct dependencies (maybe etcd and hashicorp) and follow the steps in that FAQ. That tends to work in practice to at least get someone past the majority of issues.
In any event, I certainly understand the sentiment that you would prefer that it “just work”, but I am at least trying to share some options around techniques that rely less on some of the “guess and check” you had to do initially.
… On Jan 24, 2019, at 7:08 PM, Robert van Gent ***@***.***> wrote:
I want to run go get -u and get all of my direct dependencies update to the latest, and have it work. So, b), but I don't want to have to do some manual stuff for each individual dependency (since there are dozens).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Thanks @thepudds . |
|
A few more diagnostics on
All of that suggests to me that Unfortunately, the latest tagged version of the You can observe this problem at HEAD using |
|
If you upgrade That results in a build break, which I have filed as ugorji/go#279. The workaround in the interim is to upgrade the root module past the break manually: |
|
That, unfortunately, leaves some indirect dependencies in play: However, I'm not sure whether that dependency actually causes any problems in practice: it might not break the packages that happen to be in the transitive import graph of the test. |
|
Unfortunately, with those updates Honestly, as far as I can tell the (transitive) dependencies of |
This was a pretty frustrating process. I expected to run
go get -uandgo mod tidyand be done, but it didn't work that way.go get -udoesn't work very well. When I originally ran it, I got an error in a module we don't even use: testcontainers/testcontainers-go#47. I ended up working around that by deleting everything ingo.modand lettinggo buildrebuilt it.Even now, when I run
go get -u, a whole bunch of things change ingo.modthat I don't expect given that I just basically got the latest of everything. Many of them areimplicitdependencies; I don't understand why those need to be added given that everything seems to work fine without them.The experience with a couple of our dependencies is not great either, for example
coreos. Rebuilding everything from a freshgo.modfile results in weird compile errors. I compared the resultinggo.mod/go.sumto the original one, and figured out the right incantations of manualgo getcommands that fix it, but this was painful and manual, sometimes involving inspections of the code to see what the compile error was about and what library it might come from (e.g., to get hashicorp to compile, I had to manually fetch a specific version ofSermoDigital, whatever that is).requiresection ofgo.modgo build ./... && go test ./...# ctrl-c after gcppubsub test hangsgo get google.golang.org/grpc@v1.17.0due to pubsub/gcppubsub: tests hang after upgrade to grpc v1.18.0 #1151go get github.com/coreos/bbolt@v1.3.1-coreos.6# etc.d madnessgo get github.com/coreos/etcd@v3.3.10# etc.d madnessgo get github.com/ugorji/go/codec@v0.0.0-20181012064053-8333dd449516# etc.d madnessgo get github.com/SermoDigital/jose@v0.9.2-0.20161205224733-f6df55f235c2# hashicorp madnessrm go.sumgo build ./... && go test ./...go getcommands) for./internal/contributebotand./samples/appengine.