[bug#39570] go: update to 1.13

[bug#39570] go: update to 1.13

[Jack Hill]

Hi Guix,

The following is the minimal patch to update Go to 1.13. I'm motivated to 
do this, in part, because of the go modules transition [0]. In the short 
term, this will allow users of the go tooling to use the newest modules 
behavior. The Guix go tooling, however, is not ready for modules [1], so 
in this commit, I configure the go-build-system to use the old behavior. 
Eventually the switch to do so will go away upstream, so we'll need to 
update the build system.

Some things to be aware of when reviewing:

I believe that in Go 1.13, the upstream issued that lead to excessive 
references being maintained in go programs [2] has been fixed, but I did 
not undo our workaround.

With 1.13 the behavior of `go get` changed to download packages from 
Google's mirror at proxy.golang.org by default [3] as opposed to directly 
from upstream. This is configurable by users, and I don't think it is a 
FSDG issue (if it is, I think it would be on privacy grounds), but we 
could change the default behavior if needed.

I replaced the go-1.12 package with go-1.13, rather than having both.

guix refresh -l go says that "Building the following 51 packages would 
ensure 175 dependent packages are rebuilt," so I have prepared the commit 
against master.

I tested the commit by building syncthing and restic on my x86_64 system.

[0] https://blog.golang.org/v2-go-modules
[1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00110.html
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33620
[3] https://golang.org/doc/go1.13#modules

Thanks,
Jack

[bug#39570] [PATCH] gnu: go: update to 1.13.2

[Jack Hill]

* gnu/packages/golang.scm (go-1.12): Rename to go-1.13, [version]: Update to
  1.13.7
  (go): Update to go-1.13
* guix/build/go-build-system.scm (setup-go-environment): Set GO111MODULE to
  off.
---
 gnu/packages/golang.scm        | 9 ++++-----
 guix/build/go-build-system.scm | 4 ++++
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 9102469749..798600f680 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -216,11 +216,11 @@ in the style of communicating sequential processes (@dfn{CSP}).")
     (supported-systems '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux"))
     (license license:bsd-3)))
 
-(define-public go-1.12
+(define-public go-1.13
   (package
     (inherit go-1.4)
     (name "go")
-    (version "1.12.16")
+    (version "1.13.7")
     (source
      (origin
        (method url-fetch)
@@ -228,7 +228,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
                            name version ".src.tar.gz"))
        (sha256
         (base32
-         "1y0x10fsvgpc1x24b9q9y6kv9b0kwf7879am3p0gym2abgc5wvnf"))))
+         "1x21kfpzfkvmqd42pan6nl862m7jjl4niqxxpcgm46awbz645bg4"))))
     (arguments
      (substitute-keyword-arguments (package-arguments go-1.4)
        ((#:phases phases)
@@ -367,7 +367,6 @@ in the style of communicating sequential processes (@dfn{CSP}).")
                       (docs (string-append doc_out "/share/doc/" ,name "-" ,version))
                       (src (string-append
                             (assoc-ref outputs "tests") "/share/" ,name "-" ,version)))
-                 (delete-file-recursively "../pkg/bootstrap")
                  ;; Prevent installation of the build cache, which contains
                  ;; store references to most of the tools used to build Go and
                  ;; would unnecessarily increase the size of Go's closure if it
@@ -405,7 +404,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
        ,@(package-native-inputs go-1.4)))
     (supported-systems %supported-systems)))
 
-(define-public go go-1.12)
+(define-public go go-1.13)
 
 (define-public go-github-com-alsm-ioprogress
   (let ((commit "063c3725f436e7fba0c8f588547bee21ffec7ac5")
diff --git a/guix/build/go-build-system.scm b/guix/build/go-build-system.scm
index 4bc0156a88..3337552d96 100644
--- a/guix/build/go-build-system.scm
+++ b/guix/build/go-build-system.scm
@@ -141,6 +141,10 @@ dependencies, so it should be self-contained."
   ;; Using the current working directory as GOPATH makes it easier for packagers
   ;; who need to manipulate the unpacked source code.
   (setenv "GOPATH" (getcwd))
+  ;; Go 1.13 uses go modules by default. The go build system does not
+  ;; currently support modules, so turn modules off to continue using the old
+  ;; GOPATH behavior.
+  (setenv "GO111MODULE" "off")
   (setenv "GOBIN" (string-append (assoc-ref outputs "out") "/bin"))
   (let ((tmpdir (tmpnam)))
     (match (go-inputs inputs)
-- 
2.25.0

bug#39570: [PATCH] go: update to 1.13

[Alex Griffin]

I just split this up into 2 patches and committed to master. Thanks for contributing!

-- 
Alex Griffin

[bug#39570] [PATCH] go: update to 1.13

[Jack Hill]

Alex,

Awesome, thanks for fixing it up and pushing.

Best,
Jack

[bug#39570] go: update to 1.13

[Leo Famulari]

On Tue, Feb 11, 2020 at 02:45:27PM -0500, Jack Hill wrote:
> I believe that in Go 1.13, the upstream issued that lead to excessive
> references being maintained in go programs [2] has been fixed, but I did not
> undo our workaround.

I wonder, should it be a goal to undo it?  It's not idiomatic for Guix,
but it is for Go. I had stopped thinking of it as a workaround.

> With 1.13 the behavior of `go get` changed to download packages from
> Google's mirror at proxy.golang.org by default [3] as opposed to directly
> from upstream. This is configurable by users, and I don't think it is a FSDG
> issue (if it is, I think it would be on privacy grounds), but we could
> change the default behavior if needed.

I don't see any issues here.

[bug#39570] go: update to 1.13

[Jack Hill]

On Wed, 12 Feb 2020, Leo Famulari wrote:

> On Tue, Feb 11, 2020 at 02:45:27PM -0500, Jack Hill wrote:
>> I believe that in Go 1.13, the upstream issued that lead to excessive
>> references being maintained in go programs [2] has been fixed, but I did not
>> undo our workaround.
>
> I wonder, should it be a goal to undo it?  It's not idiomatic for Guix,
> but it is for Go. I had stopped thinking of it as a workaround.

Perhaps not. I don't see a strong need to revert, but wanted to point out 
that the original reason for doing that had changed.

Best,
Jack