Our solution to this was, against advice otherwise, to put go.sum in .gitignore and to rev all the co-dependent modules together simultaneously. As you said, it *was* really unpleasant. In the 3 days since I posted I've since had to do it again.
Is there a "Go modules therapy group" (or at least "Go modules haters club")? I struggled to get our adoption of modules finalized for almost 9 straight days. Now I'm exhausted and have a lot of very unhealthy negative energy that I need to vent regarding modules. Its cast quite a shadow on my enjoyment of the language. If I'm honest with myself, I wince every time I use it now. Today I went to do a basic 'go run foobar.go' of a piece of prototype test code in a bare directory I was working with before upgrading to 1.16 and it gave me a "working directory is not part of a module" error because it imports an external package. I nearly lost my mind. Bart On Monday, March 1, 2021 at 11:39:34 AM UTC-8 Bryan C. Mills wrote: > On Thu, Feb 25, 2021 at 7:43 PM Bart Grantham <ba...@bartgrantham.com> > wrote: > >> If I understand the post here, it seems we're also struggling with this >> issue with our private repos. For us it means that in the go.sum of the >> highest level repos there's references for everything, all the way back to >> the initial v0.0.0 versions of every package. AFAICT, this is happening >> with public modules as well. I tried using modgraphviz to visualize our >> graph, it was hilariously large and it even generated a warning that it had >> to be scaled down in order for cairo to draw it. >> >> If I can make an observation, and I may be totally wrong, this is a >> symptom of the linker's dependency graph and the module dependency graph >> being defined differently. For the purposes of keeping go.sum tidy the >> linker's relaxed dependency graph is what I would expect, but I haven't >> really thought that through. Looking at the proposal, it is clear that >> this is a very hairy problem. >> >> In the meantime our go.sum's are growing monotonically. Does this mean >> our ~/go/pkg/mod/ directories are also growing monotonically? Mine is >> looking pretty heavy these days. >> > > Yes, if you go.sum file is growing monotonically then your module cache is > probably also growing monotonically. > > That said, for requirement cycles the only checksums (and the only module > cache contents) that should actually be needed are for the …/go.mod paths, > which contain the checksums for the go.mod files only (not the complete > source code). So while it's true that your module cache is “growing > monotonically”, the coefficient of growth should be small. > > (Even a small coefficient can be a problem over the long term, of course — > that's why we're also working on a long-term fix in the `go` command. 🙂) > -- 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/c949bba9-4455-4f01-9538-688fb9fca6ebn%40googlegroups.com.
