On Thursday, March 14, 2019 at 6:52:52 AM UTC+1, Wael Nasreddine wrote:
>
> I'm going to describe how I ended up packaging the go modules (and so far
> it seems to work correctly). I have also replied inline below
>
> I'm using a two-phase approach to package Go modules for Nix:
>
> 1. During the first phase, a package named after the module with the
> suffix *-go-modules* is built by running *go mod download* and saving
> only $GOPATH/pkg/mod/cache/download
>
> <https://github.com/NixOS/nixpkgs/blob/c7172377f4743a079dc004bf880627f5ad521f2c/pkgs/development/go-modules/generic/default.nix#L62-L85>.
>
> The contents of this package are then hashed and compared against a fixed
> known hash. The build fails if the hash does not match. My only concern is
> with regards to the stability of $GOPATH/pkg/mod/cache/download, does it
> ever change given the exact same go.mod?
>
>
No, it shouldn't. There are vxxx.ziphash files for each version.
>
> 1. The Go module is then built with $GOPROXY set to
> file://${go-modules}
>
> <https://github.com/NixOS/nixpkgs/blob/c7172377f4743a079dc004bf880627f5ad521f2c/pkgs/development/go-modules/generic/default.nix#L101-L109>
>
> and allows Go to download the dependencies locally. No concerns during
> this
> step.
>
>
> On Wednesday, March 13, 2019 at 2:31:27 PM UTC-7, Manlio Perillo wrote:
>>
>> Not precisely. In my case, I'm doing the build in two stages a) fetch
>>> dependencies and make sure they pass the hash and b) use (a) to build the
>>> module. I can add patches to the stage (a) to patch dependencies, but
>>> obviously, it does need some patching work due to the path of the
>>> dependency itself. I'm not too worried about patching at this time as I'm
>>> more worried about packaging instead.
>>>
>>>
>>
>> This is how I would do things in order to have a consistent snapshot of
>> Go modules for an OS distribution:
>>
>> 1) Clone each repository of the Go modules you want to include in the
>> snapshot, and all the indirect dependencies
>> 2) Patch all the go.mod files to ensure that *only* one version
>> of each module is used. Do not rely on cmd/go dependency
>> resolution algorithm
>> 3) Synthesize a Go module data for each repository, and make
>> it accessible from GOPROXY
>> 4) Build
>>
>> Note that 2) will cause hash checks to fail; this is where -mod=trust
>> came to help.
>>
>>
> What's wrong with using the Go toolchain to grab the dependencies with go
> mod download?
>
>
Nothing, it is just that I have never used it and when I tried to use it I
didn't notice that it *requires* a version.
However, how do you find all the direct and indirect dependencies of a
module?
In my test I created a temporary directory with a temporary module named
snapshot, and use go get do download a module.
Then I use go mod graph to get all the dependencies, save them and delete
the temporary directory.
Regards
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.
