@worldofpeace

• fixed version
• moved to servers
• added index.html to out

Example usage: https://github.com/rvolosatovs/infrastructure/blob/fae0779f897a527a628f5faeca88bcb61df12be4/nixos/echoip.nix#L17

...And fixed a typo

The project uses go modules - I did not find an automated solution to convert the go module files into deps.nix, so I first converted it to use dep, then used to dep2nix to generate the deps.nix.
Still had to do some manual tweaking to make it build, however, as golang.org/x/sys was not included in deps.nix by some reason.

To be fair that sounds kind of scary 😄
I'm not sure if anything is being done for the new go modules stuff.

Tried to build it and got

fixed-output derivation produced path '/nix/store/ll9hiknw3w3n4l3l0in3fff0p52wmraq-geoip2-golang-7118115' with sha256 hash '0d3kykb1xqh4a1qkpsbl7bbk1pcffshj2dvp5b3xrhyvxfs2cdxs' instead of the expected hash '0zpgpz577rghvgis6ji9l99pq87z5izbgzmnbyn3dy533bayrgpw'

So I think one of the hashes in the deps.nix is wrong.

Corrected the hash manually just to test with https://github.com/rvolosatovs/infrastructure/blob/fae0779f897a527a628f5faeca88bcb61df12be4/nixos/echoip.nix#L17 and it does work.

A NixOS module would be nice too, but it's not required.

Regarding the module:
It would be nice indeed, however a use case for this service would be quite niche I think.
Maybe in a follow-up PR?

Regarding the hash:
The issue seems to be because of the submodules in https://github.com/oschwald/geoip2-golang, which are only used for testing.
This is the output of
nix-prefetch-git --rev 711811 https://github.com/oschwald/geoip2-golang

{
  "url": "https://github.com/oschwald/geoip2-golang",
  "rev": "7118115686e16b77967cdbf55d1b944fe14ad312",
  "date": "2018-02-22T13:45:52-08:00",
  "sha256": "0zpgpz577rghvgis6ji9l99pq87z5izbgzmnbyn3dy533bayrgpw",
  "fetchSubmodules": false
}

And
nix-prefetch-git --rev 711811 --fetch-submodules https://github.com/oschwald/geoip2-golang

{
  "url": "https://github.com/oschwald/geoip2-golang",
  "rev": "7118115686e16b77967cdbf55d1b944fe14ad312",
  "date": "2018-02-22T13:45:52-08:00",
  "sha256": "0d3kykb1xqh4a1qkpsbl7bbk1pcffshj2dvp5b3xrhyvxfs2cdxs",
  "fetchSubmodules": true
}

I tried to turn the dependency in deps.nix into:

  {
    goPackagePath  = "github.com/oschwald/geoip2-golang";
    fetch = {
      type = "git";
      url = "https://github.com/oschwald/geoip2-golang";
      rev =  "7118115686e16b77967cdbf55d1b944fe14ad312";
      sha256 = "0zpgpz577rghvgis6ji9l99pq87z5izbgzmnbyn3dy533bayrgpw";
      fetchSubmodules = false;
    };
  }

But that does not seem to help and submodules are still pulled in.(and, hence, there's a hash mismatch). Any ideas on how to fix this?

rg 'fetchSubmodules|submodule' $(find $(nix eval '(<nixpkgs>)') -name 'deps.nix')

Does not find anything either, is it not possible to control the submodule fetching in go package builds?

@rvolosatovs

Looking at the buildGoPackage source, this looks pertinent:

dep2src = goDep:
    {
      inherit (goDep) goPackagePath;
      src = if goDep.fetch.type == "git" then
        fetchgit {
          inherit (goDep.fetch) url rev sha256;
        }
...

It doesn't care about fetchSubmodules = false;. That's probably something we should fix in the future.

If you want to you can work around this by changing the fetch type to FromGitHub which will use a github archive without any submodules.

 {
    goPackagePath  = "github.com/oschwald/geoip2-golang";
    fetch = {
      type = "FromGitHub";
      owner = "oschwald";
      repo = "geoip2-golang";
      rev =  "7118115686e16b77967cdbf55d1b944fe14ad312";
      sha256 = "0zpgpz577rghvgis6ji9l99pq87z5izbgzmnbyn3dy533bayrgpw";
    };
  }

(hash retrieved from nix-prefetch-github)

@worldofpeace implemented the workaround

Still getting a hash issue so I think the FetchGitHub workaround is still needed.

fixed-output derivation produced path '/nix/store/g2x3lfhppx3g9lwrffjxkjwal7cz51ki-geoip2-golang' with sha256 hash '0d3kykb1xqh4a1qkpsbl7bbk1pcffshj2dvp5b3xrhyvxfs2cdxs' instead of the expected hash '0zpgpz577rghvgis6ji9l99pq87z5izbgzmnbyn3dy533bayrgpw'

@rvolosatovs
I went ahead and fixed this up in fc42a76.
Thanks for working on this.