On Mon, Mar 11, 2019 at 3:02 AM Manlio Perillo <manlio.peri...@gmail.com> wrote:
> On Monday, March 11, 2019 at 6:12:05 AM UTC+1, Wael Nasreddine wrote: >> >> On Sunday, March 10, 2019 at 6:44:10 PM UTC-7, Manlio Perillo wrote: >>> >>> On Monday, March 11, 2019 at 2:06:44 AM UTC+1, Wael Nasreddine wrote: >>>> >>>> >>>> >>>> On Sunday, March 10, 2019 at 5:01:01 PM UTC-7, Manlio Perillo wrote: >>>>> >>>>> On Monday, March 11, 2019 at 12:30:02 AM UTC+1, Wael Nasreddine wrote: >>>>>> >>>>>> TL;DR Given a Go module, assuming that I have already done `go mod >>>>>> download`: Is it possible to prevent network access if I delete the >>>>>> entire >>>>>> `$GOPATH/pkg/mod/cache`? >>>>>> >>>>>> >>>>> Yes. Use `go mod vendor` and the -mod=vendor build flag. >>>>> >>>> >>>> This works! Thank you! >>>> >>>> Is the vendor mode going to be supported per Go 1.x compatibility? As >>>> in, can I assume it works for all 1.x versions >= 1.11? >>>> >>> >>> Go 1.x compatibility does not cover the go tools. >>> >>> However the vendor mode should remain because it was added to solve a >>> specific use case, and has nothing to do with the old vendoring support: >>> https://golang.org/cmd/go/#hdr-Modules_and_vendoring >>> >>> See also: >>> https://golang.org/cmd/go/#hdr-Maintaining_module_requirements >>> >>> "If invoked with -mod=vendor, the go command assumes that the vendor >>> directory holds the correct copies of dependencies and ignores the >>> dependency descriptions in go.mod." >>> >>> >> Thank you for the documentation link, this is very helpful! >> >> On Sunday, March 10, 2019 at 6:59:07 PM UTC-7, Manlio Perillo wrote: >>> >>> On Monday, March 11, 2019 at 12:30:02 AM UTC+1, Wael Nasreddine wrote: >>>> >>>> TL;DR Given a Go module, assuming that I have already done `go mod >>>> download`: Is it possible to prevent network access if I delete the entire >>>> `$GOPATH/pkg/mod/cache`? >>>> >>>> >>> Another solution is to delete only $GOPATH/pkg/mod/cache/vcs. This is >>> the directory that takes more disk space since it contains the full history >>> of the vcs. >>> >> >> That was my first attempt, however it did not work as expect because the >> contents of $GOPATH/pkg/mod/cache/download does change anytime a new >> version is created upstream. My hash failed to match multiple times a day! >> > > It may be caused by the missing pkg/mod/cache/vcs, but it seems unusual. > I was assuming GOPATH was on a temporary directory. > And indeed you wrote that GOPATH is set to $NIX_BUILD_TOP/go, but later > you wrote that it is set to a temporary directory. > > I am removing the entire cache folder, as the content changes when the git repository of any of the dependencies change. So if I would hash the cache folder to A and one of the dependencies get a pull request merged upstream, even though it does not technically change the version that Go is building with you will still get B when you hash it. This break the concept of packaging :( You can try with the following flow (not tested). > > 1. download modules with `go mod download` > 2. *copy* the content of $GOPATH/pkg/mod/cache/download to the output > directory > 3. set GOPROXY=file:///$out/... when you `go build` > > See also https://roberto.selbach.ca/go-proxies/ > > This is quite interesting, thank you for this! However, as I said above the contents of the download directory changes as upstream changes :( -- 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. For more options, visit https://groups.google.com/d/optout.
