Hello Russ, Usually, if you are not modifying your code, I think go.mod should be stable across repeated identical invocations of something like 'go build' or 'go install'.
I think there were a similar sounding set of bugs fixed for Go 1.13, but sounds like you are seeing this with Go 1.13. A more recent bug was this one, which I think was reported against Go 1.13: https://github.com/golang/go/issues/34086 That particular bug has seemingly been fixed in the tip branch. It probably is worth trying to see if you can reproduce with that fix in place. A handy way to try with the latest from tip / master is: $ go get golang.org/dl/gotip $ gotip download However, that might not solve it for you. If you still see the same behavior using 'gotip', then I would suggest opening a new bug to make sure one of the people working on cmd/go takes a look. It looks like you already have nicely pulled together a public reproducer, which is great. Finally, does 'go mod tidy' seem to be stable in terms of how it leaves go.mod? If so, one approach in the short term might be to run 'go mod tidy' to put go.mod into a more stable state (e.g., after running 'go install'), but given you seem to be seeing a bug, I'm not sure if that will work for you. Regards, thepudds On Wednesday, September 18, 2019 at 7:38:41 PM UTC-4, Russ Selph wrote: > > Hi, > > I've got a modules problem, and I'm not sure yet whether it's operator > error or something worthy of a bug report. In short, I have a build where > go.mod oscillates between two states build by build. The first build > changes it one way, the next build changes it back. If I try the build > with -mod=readonly, it will always fail because every build wants to change > go.mod. This is a real problem for source control. :-) > > I've put together a toy project that demonstrates the problem. It's based > on our real world project, which is pretty large. This one has no code of > any consequence, but is an exact model of the external dependencies. > > https://github.com/rselph-tibco/go-unstable-mods > > There are two programs and two packages, all contained in two modules, > with a sort of twisted interdependency. But it seems to be the external > dependencies that are messing things up. On subsequent builds of sample1, > the go.mod file does this: > > foo.com/me/sample2 v0.0.0-00010101000000-000000000000 > github.com/coreos/bbolt v1.3.3 > github.com/coreos/etcd v3.3.15+incompatible > - github.com/coreos/go-semver v0.3.0 // indirect > github.com/elazarl/go-bindata-assetfs v1.0.0 > github.com/gorilla/mux v1.7.3 > - github.com/json-iterator/go v1.1.7 // indirect > github.com/magiconair/properties v1.8.1 > - github.com/modern-go/reflect2 v1.0.1 // indirect > github.com/satori/go.uuid v1.2.0 > golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab > > then this: > > foo.com/me/sample2 v0.0.0-00010101000000-000000000000 > github.com/coreos/bbolt v1.3.3 > github.com/coreos/etcd v3.3.15+incompatible > + github.com/coreos/go-semver v0.3.0 // indirect > github.com/elazarl/go-bindata-assetfs v1.0.0 > github.com/gorilla/mux v1.7.3 > + github.com/json-iterator/go v1.1.7 // indirect > github.com/magiconair/properties v1.8.1 > + github.com/modern-go/reflect2 v1.0.1 // indirect > github.com/satori/go.uuid v1.2.0 > golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab > > What's the best way to debug what's going on here? Does this look like > any known problem? (Search didn't yield anything that looked similar to > me.) > > You can follow the exact steps and their consequences here: > https://github.com/rselph-tibco/go-unstable-mods/commits/master > All of that was generated by the script at > https://github.com/rselph-tibco/go-unstable-mods/blob/master/run.sh > -- 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/63ac661b-7d10-466f-9652-aaf0b2d8f90e%40googlegroups.com.
