Thanks for the tips. I'll try to reproduce from the tip branch before filing a bug.
On Thursday, September 19, 2019 at 9:34:38 AM UTC-7, t hepudds wrote: > > 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/eeb8a4e6-feca-4a80-8606-00d2e5c07fd0%40googlegroups.com.
