Hi Wael,
Sorry, I am not quite following what you have and have not tried yet, and
which issues you have hit with which techniques.
Is one of the issues that the 'vcs' cache directory changes, even if the
actual code you need for your build has not changed?
If so, I wonder if you might be able use a filesystem-based module cache
via 'GOPROXY=file:///file/path', which could avoid using the 'vcs'
directory at build time?
It sounds like you have looked into multiple options at this point, so this
might be well known to you at this point, but:
* The module download cache location is controlled by GOPATH. In
particular, 'go mod download', 'go build', etc. populate the module cache
in GOPATH/pkg/mod.
* In addition, when you want to use a particular module cache, you can
tell the 'go' command to use a local module cache by setting
'GOPROXY=file:///file/path' environment variable.
* You can put those two things together:
# Populate a module download cache in /tmp/gopath-for-cache
$ GOPATH=/tmp/gopath-for-cache go mod download
# Build using the contents of the module download cache in
/tmp/gopath-for-cache
$ GOPROXY=file:///tmp/gopath-for-cache/pkg/mod/cache/download go build
Note that /tmp/gopath-for-cache/pkg/mod/cache/download would not contain
the 'vcs' directory.
I understand those are not the exact steps you would follow, but perhaps
something along those lines could be adapted within your constraints?
Also, note that even though you are setting the GOPROXY environment
variable in the steps above, there is no actual proxy process involved, and
everything is just being read directly from the local filesystem. An even
more detailed example is here in this "Go Modules by Example" walk-through:
https://github.com/go-modules-by-example/index/tree/master/012_modvendor
Sorry if anything here is off-base, or if this is not helpful.
Regards,
thepudds
On Monday, March 11, 2019 at 1:01:04 PM UTC-4, Manlio Perillo wrote:
>
> On Monday, March 11, 2019 at 4:22:04 PM UTC+1, Wael Nasreddine wrote:
>
> > [...]
>
>
>> 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 :(
>>
>>
> Do you perhaps have the same requirements as in the thread
> https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI
> as reported by Nicolas Mailhot?
>
> That is, you need to patch the upstream source but keep the same version,
> because you can't (or don't want to) update all the versions of the
> required modules.
>
> In this case vendoring is, IMHO, currently the only solution, because the
> go tool ignores the go.sum files in this case.
> You can try to open a bug report about the incorrect behavior of `go mod
> vendor` when using cgo.
>
> Or you can patch cmd/go. However instead of writing a patch specific to
> Nix, I suggest to write a more generic patch.
>
> You can add a new module download mode, e.g. `-mod trust` to instruct
> cmd/go to not check go.sum.
> The future notary can be disabled with GONOVERIFY, so its not a problem.
> Maybe you can use GONOVERIFY to decide if the checksum should be ignored.
>
> Finally, you can try to coordinate with other package managers, since this
> seems to be a shared problem.
>
> Here is a patch. It seems to work but one the Go test fails, and it
> should probably be updated:
> https://gist.github.com/perillo/813b52dcff8824da3a2859828961d08b
>
> An alternative is to check for trust mode in the initGoSum function:
> https://gist.github.com/perillo/1b3d3216c59f689e52ee7357d2a99136
>
> Finally the last alternative is to check for trust mode in the checkGoMod
> function, but this will also disable the notary. Maybe it is the correct
> thing to do:
> https://gist.github.com/perillo/59f3be87dd2b64d7d734c74d1f344cd5
>
> > [...]
>
>
> Manlio Perillo
>
--
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.
