go.mod changes on each build, -mod=readonly can never work

[Russ Selph]

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

[t hepudds]

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

[Russ Selph]

Thanks for the hints.  I'll try to reproduce from the tip branch before filing a bug.

-- 
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JD9pxtPIxHg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@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.

[rselph]

Thanks for the tips.  I'll try to reproduce from the tip branch before filing a bug.

[Russ Selph]

I’ve filed this as #34417, at https://github.com/golang/go/issues/34417