Go: update path to zoneinfo.zip

[fmpwizard]

Issue description

A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file.

Steps to reproduce

1. write main,go file with:

package main

import (
	"log"
)

func main() {
	l, err := time.LoadLocation("America/New_York")
	if err != nil {
		log.Fatalln("failed to read timezone file: ", err)
	}
	log.Println("All went well: " + l.String())
}

default.nix:

# This pins the packages to certain versions
with import (builtins.fetchTarball {
  # Descriptive name to make the store path easier to identify
  name = "nixos-unstable-2019-01-22";
  # Commit hash for nixos-unstable as of 2019-01-22
  url = https://github.com/NixOS/nixpkgs/archive/51d88f7d20ea6f992934927539bd3caea28bcec6.tar.gz;
  # Hash obtained using `nix-prefetch-url --unpack <url>`
  sha256 = "198c54x34c03pv48xq7sh3b81q5wl0h3g7gq240s31q56zc6jpr3";
}) {};

stdenv.mkDerivation rec {
  name = "env";
  env = buildEnv { name = name; paths = buildInputs; };
  buildInputs = [
    go
  ];
}

$nix-shell
$go build
$exit
$ ./app # name of the app you just created
2019/01/25 20:04:58 All went well: America/New_York

Now copy this file to another computer

#./app
2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go-1.11.4/share/go/lib/time/zoneinfo.zip: no such file or directory

The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced

/usr/share/zoneinfo/
with
/nix/store/bgzqg5q8q1gpsbmpy4mavvnjzy528c8l-tzdata-2018g/share/zoneinfo/

I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing.

Technical details

$ nix-shell -p nix-info --run "nix-info -m"
these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info
copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from 'https://cache.nixos.org'...

• system: "x86_64-linux"
• host os: Linux 4.4.0-141-generic, Ubuntu, 16.04.5 LTS (Xenial Xerus)
• multi-user?: no
• sandbox: no
• version: nix-env (Nix) 2.0
• channels(diego): "nixpkgs-18.03pre130569.7a04c2ca296"
• nixpkgs: /home/diego/.nix-defexpr/channels/nixpkgs

version is nixos-unstable-2019-01-22

The file pkgs/development/compilers/go/1.11.nix replaces the path that the go runtime looks for the timezone information.

Original Go code is:

var zoneSources = []string{
        "/usr/share/zoneinfo/",
        "/usr/share/lib/zoneinfo/",
        "/usr/lib/locale/TZ/",
        runtime.GOROOT() + "/lib/time/zoneinfo.zip",

But nix changes the first entry, "/usr/share/zoneinfo/" for ${tzdata}/share/zoneinfo/

This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like /nix/store/bgzqg5q8q1gpsbmpy4mavvnjzy528c8l-tzdata-2018g/share/zoneinfo/

isn't present on the separate server and then the lookup fails.

"/usr/share/zoneinfo/" is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep "/usr/share/zoneinfo/" and the other entries as they are in the original go source code.

The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.

[FRidh]

I doubt anyone ever considered support for non-Nix and therefore I will mark it also as wontfix. I'll leave it open for now as maybe it can be supported (I doubt it).

[fmpwizard]

@FRidh would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.

[fmpwizard]

cross referencing a thread on the mailing list about this ticket/issue

https://discourse.nixos.org/t/go-zoneinfo-zip-wrong-path-update-in-build/2365

so both conversations are linked.

[veprbl]

@fmpwizard Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.