Consider (optionally) maintaining separate GOPATH for each installation (or at least use tmp one)

[bwplotka]

The reason is that I found Go modules really problematic if you want to revert or install a various version of the same tools where most of the projects do not use version properly (they do breaking changes in minor versions) it ends up being impossible (you can find buildable version). All until you remove the GOPATH/mod. All suddenly works. I think Go Module prefers already cached items? By not working I mean that Go Modules is always confused by ambigous packages and some other problems.

In Go 1.15 it's super easy: https://twitter.com/inancgumus/status/1266041878379737088 and for Go 1.14 we can use some top one.

Decisions to make here:

• Am I right that using new $GOPATH/mod is sometimes necessary for correct use?
• Should we always install / download module in separate mod dir? I find this tricky as it consumes extreme amount of disk space sometimes.
• Should we always use tmp module dir? This will make our deps to never be cached anywhere
• Should we give an option for user?

[bwplotka]

cc @Helcaraxan maybe you will know :hugs: (: Maybe I need to double check if old .sum is cleared just to make sure Go Modules will work smoother.

[sh0rez]

While I feel like I experienced similar things, I'd like to see some real reproducible example before considering this.

A possible downside might be the loss of caching (haha), which might result in duplicated downloads.

[Helcaraxan]

@bwplotka I am not entirely sure about the nature of the problem that you are facing. Could you give an example of what you are doing, what you would expect to happen and what happens instead.

In a more generic fashion:

• What's available locally in the cache (and what isn't) should not influence the result from running any go command that interacts with modules.
• The new GOMODCACHE path is targeted at different concerns (i.e persisting caches in CI, lower-level module tooling, etc).

[bwplotka]

Perfect, once me or anyone experience such issue will try to dig more details and paste here (: Thanks!

On Fri, 29 May 2020 at 13:40, Duco van Amstel [email protected] wrote:

@bwplotka https://github.com/bwplotka I am not entirely sure about the nature of the problem that you are facing. Could you give an example of what you are doing, what you would expect to happen and what happens instead.

In a more generic fashion:

• What's available locally in the cache (and what isn't) should not influence the result from running any go command that interacts with modules.
• The new GOMODCACHE path is targeted at different concerns (i.e persisting caches in CI, lower-level module tooling, etc).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bwplotka/bingo/issues/11#issuecomment-635950461, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA3O3KTAG4TUROOCVJI43RT6ULTANCNFSM4NN6RANA .

[bwplotka]

Now I have something similar again.

While being on fresh project with it's own go.mod like this:

module testproject

go 1.14

require (
	github.com/oklog/run v1.1.0
	github.com/pkg/errors v0.9.1
)

And go.sum:

github.com/oklog/run v1.1.0 h1:GEenZ1cK0+q0+wsJew9qUg/DyD8k3JzYsZAi5gYi2mA=
github.com/oklog/run v1.1.0/go.mod h1:sVPdnTZT1zYwAJeCMu2Th4T21pA3FPOQRfWjQlk7DVU=
github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=

I released bingo v0.1.0and I tried in this project togo get` it.

So I did: go get -u github.com/bwplotka/bingo

This brings v0.1.0-rc.4 despite -u which asks for upgrade:

go: github.com/bwplotka/bingo upgrade => v0.1.0-rc.4
go: golang.org/x/mod upgrade => v0.3.0
go: golang.org/x/xerrors upgrade => v0.0.0-20191204190536-9bdfabe68543

unset GOPROXY does not help either (I thought it's some cache somewhere).

sudo rm -rf ${GOPATH}/pkg/mod/github.com/bwplotka/[email protected] does not help.

What helps?

I had to manually get v0.1.0: go get github.com/bwplotka/[email protected]

Only then go get -u github.com/bwplotka/bingo was giving v0.1.0... :facepalm: any ideas who designed this? or is it a bug?

[Helcaraxan]

@bwplotka how much time elapsed between you tagging v0.1.0 and you doing the go get -u github.com/bwplotka/bingo? If it's less than 5-15m the module proxy might not have yet picked up the new tag.

In order to deactivate the module proxy for your module the best is to simply set GOPRIVATE=github.com/bwplotka/bingo, if you want to deactivate it completely you should set GOPROXY=direct, if you unset the variable then it will just get the default baked-in value in go itself which will be proxy.golang.org,direct unless you are on Fedora in which case it will be direct.

[bwplotka]

Perfect, this makes sense. Super cool!

On Sat, 30 May 2020 at 23:49, Duco van Amstel [email protected] wrote:

@bwplotka https://github.com/bwplotka how much time elapsed between you tagging v0.1.0 and you doing the go get -u github.com/bwplotka/bingo? If it's less than 5-15m the module proxy might not have yet picked up the new tag.

In order to deactivate the module proxy for your module the best is to simply set GONOPROXY=github.com/bwplotka/bingo, if you want to deactivate it completely you should set GOPROXY=direct, if you unset the variable then it will just get the default value baked-in value in go which will be proxy.golang.org,default unless you are on Fedora in which case it will be direct.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bwplotka/bingo/issues/11#issuecomment-636394868, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA3O2ZLGHIIG6SMI7JFTLRUGEPZANCNFSM4NN6RANA .