Updating from Go 1.17 to 1.18

Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin]

[-- Attachment #1.1: Type: text/plain, Size: 473 bytes --]

Hello,

I am trying to update Go to 1.18, I do have a *working* patch that defines
a package that inherits from 1.17 and that adjusts the inputs. However, I
have a few questions:

1. Is inheriting the way to do that? The package's build system appears to
be the same from 1.17.
2. How can I rebuild dependents packages to ensure they are still building
correctly?
3. Anything I should look into or test more for these kinds of packages?

Thanks

-- 
ph,
http://heykimo.com

[-- Attachment #1.2: Type: text/html, Size: 769 bytes --]

[-- Attachment #2: go-1.18 --]
[-- Type: application/octet-stream, Size: 1687 bytes --]

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index f3cc1bd6b8..225331ab97 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -33,7 +33,7 @@
 ;;; Copyright © 2021 Chadwain Holness <chadwainholness@gmail.com>
 ;;; Copyright © 2021 Philip McGrath <philip@philipmcgrath.com>
 ;;; Copyright © 2021 Lu Hui <luhux76@gmail.com>
-;;; Copyright © 2022 Pier-Hugues Pellerin <phpellerin@gmail.com>
+;;; Copyright © 2022 Pier-Hugues Pellerin <ph@heykimo.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -838,7 +838,30 @@ (define-public go-1.17
        (alist-replace "go" (list go-1.16) (package-native-inputs go-1.16))
        (package-native-inputs go-1.16)))))
 
-(define-public go go-1.17)
+(define-public go-1.18
+  (package
+    (inherit go-1.17)
+    (name "go")
+    (version "1.18")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/golang/go")
+             (commit (string-append "go" version))))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32
+         "1i4cn9p0viypnq3vn64zpi1rc8615cqhzay25hmy46n4r2mvhv3s"))))
+    (inputs (if (not (target-arm?))
+                (alist-delete "gcc:lib" (package-inputs go-1.17))
+                (package-inputs go-1.17)))
+    (native-inputs
+         (if (not (member (%current-system) (package-supported-systems go-1.4)))
+             (alist-replace "go" (list go-1.17) (package-native-inputs go-1.17))
+             (package-native-inputs go-1.17)))))
+
+(define-public go go-1.18)
 
 (define-public (make-go-std go)
   "Return a package which builds the standard library for Go compiler GO."

Re: Updating from Go 1.17 to 1.18

[Ludovic Courtès]

Hi,

Pier-Hugues Pellerin <ph@heykimo.com> skribis:

> I am trying to update Go to 1.18, I do have a *working* patch that defines
> a package that inherits from 1.17 and that adjusts the inputs.

Nice!

> However, I have a few questions:
>
> 1. Is inheriting the way to do that? The package's build system appears to
> be the same from 1.17.
> 2. How can I rebuild dependents packages to ensure they are still building
> correctly?
> 3. Anything I should look into or test more for these kinds of packages?

You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
both versions, and eventually we’ll remove the older one.

Note that, to actually migrate Go packages to 1.18, you’ll need to
additionally change this line:

  (define-public go go-1.17)

‘guix refresh -l go@1.17’ shows the “contour” of the set of packages
that currently depend on Go 1.17.  These are all the packages that need
to be rebuilt if you change the line above.  Since that’s a lot of them,
we could set up a dedicated branch and have it built by ci.guix.  We’d
merge it once problems have been resolved.

Does that make sense?

Thanks,
Ludo’.

Re: Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

Hello,

I think it makes sense, looking at the number of impacted packages and from
my experience working
in go, even if the contract is the same, sometimes it does break on minor.

One more thing, should I do it in two patches like this?

1. Add go 1.18 inheriting from 1.17, allowing people to use 1.18 sooner?
2. Move to the default Go to 1.18 with (define-public go go-1.17) and
create the testing branch from that?

Thanks for the `refresh` tips.


On Sun, Apr 10, 2022 at 4:45 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Pier-Hugues Pellerin <ph@heykimo.com> skribis:
>
> > I am trying to update Go to 1.18, I do have a *working* patch that
> defines
> > a package that inherits from 1.17 and that adjusts the inputs.
>
> Nice!
>
> > However, I have a few questions:
> >
> > 1. Is inheriting the way to do that? The package's build system appears
> to
> > be the same from 1.17.
> > 2. How can I rebuild dependents packages to ensure they are still
> building
> > correctly?
> > 3. Anything I should look into or test more for these kinds of packages?
>
> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
> both versions, and eventually we’ll remove the older one.
>
> Note that, to actually migrate Go packages to 1.18, you’ll need to
> additionally change this line:
>
>   (define-public go go-1.17)
>
> ‘guix refresh -l go@1.17’ shows the “contour” of the set of packages
> that currently depend on Go 1.17.  These are all the packages that need
> to be rebuilt if you change the line above.  Since that’s a lot of them,
> we could set up a dedicated branch and have it built by ci.guix.  We’d
> merge it once problems have been resolved.
>
> Does that make sense?
>
> Thanks,
> Ludo’.
>


-- 
ph,
http://heykimo.com

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]

Re: Updating from Go 1.17 to 1.18

[Katherine Cox-Buday]

>>> Pier-Hugues Pellerin <ph@heykimo.com> writes:
>> Ludovic Courtès writes:

>>> I am trying to update Go to 1.18, I do have a *working* patch that defines
>>> a package that inherits from 1.17 and that adjusts the inputs.
>>
>> Nice!

Yes, thank you! I just found out I need this and came to see if anyone had
started on it.

>> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have both
>> versions, and eventually we’ll remove the older one.

I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make go-1.17
inherit from go-1.18. This means that when it's time to sunset a version, it's
a simple delete and not something that cascades through all recent versions.

> I think it makes sense, looking at the number of impacted packages and from
> my experience working in go, even if the contract is the same, sometimes it
> does break on minor.

I was wondering if we don't want to start publishing a go-next package like we do with emacs-next? That would allow us to publish the latest version of Go without needing to immediately address building all the packages that depend on it.

Kindest regards,
-- 
Katherine

Re: Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

That sound great and great timing I was working on that as you send the mail

I think also go-next is a good idea, I will split them in the following
commits:

1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the
previous email)
2. Add go-next pointing to 1.18.
3. Make go point to 1.18.

This will allow merging things right away to add support for go 1.18 and
also allow Ludovic to create the branch and rebuild.

Thanks

On Wed, Apr 20, 2022 at 7:36 PM Katherine Cox-Buday <
cox.katherine.e@gmail.com> wrote:

> >>> Pier-Hugues Pellerin <ph@heykimo.com> writes:
> >> Ludovic Courtès writes:
>
> >>> I am trying to update Go to 1.18, I do have a *working* patch that
> defines
> >>> a package that inherits from 1.17 and that adjusts the inputs.
> >>
> >> Nice!
>
> Yes, thank you! I just found out I need this and came to see if anyone had
> started on it.
>
> >> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
> both
> >> versions, and eventually we’ll remove the older one.
>
> I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make
> go-1.17
> inherit from go-1.18. This means that when it's time to sunset a version,
> it's
> a simple delete and not something that cascades through all recent
> versions.
>
> > I think it makes sense, looking at the number of impacted packages and
> from
> > my experience working in go, even if the contract is the same, sometimes
> it
> > does break on minor.
>
> I was wondering if we don't want to start publishing a go-next package
> like we do with emacs-next? That would allow us to publish the latest
> version of Go without needing to immediately address building all the
> packages that depend on it.
>
> Kindest regards,
> --
> Katherine
>


-- 
ph,
http://heykimo.com

[-- Attachment #2: Type: text/html, Size: 2570 bytes --]

Re: Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin]

[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]

Hello,

I've looked a bit more in detail on the Go package definition, Maybe we
should rethink how we are building the Go package in guix?
If I understand correctly, the current bootstrap chain is the following.

1.17 -> 1.16-> 1.4 which is the last gcc version of go.

Looking at the current proposal in Go
https://mail.google.com/mail/u/0/#inbox/KtbxLthKLdQNrjXvKllfQHQBQcKqVFdmPg
I don't think we will be able to remove 1.17 soon and also 1.4.  Because
they want to move to use 1.17 as the minimum
 version in the next minor.

We should probably also try to mimic how their bootstrap and have the
following:

   - Bootstrap 1.17 with 1.4
   - Bootstrap 1.18 with 1.4
   - Have 1.19 bootstrap with 1.17.

So maybe we should do something like this.

- Add go-1.18 build from 1.4.
- Add go-next that point to go-1.18
- Refactor 1.17 package definition that is shared between go-1.18. and
go-1.17.
- Move  go to go-1.18  in another branch
- Remove 1.16?

WDYT? I am not super familiar with the scheme but this seems like a good
exercise.

Thanks


On Wed, Apr 20, 2022 at 7:43 PM Pier-Hugues Pellerin <ph@heykimo.com> wrote:

> That sound great and great timing I was working on that as you send the
> mail
>
> I think also go-next is a good idea, I will split them in the following
> commits:
>
> 1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the
> previous email)
> 2. Add go-next pointing to 1.18.
> 3. Make go point to 1.18.
>
> This will allow merging things right away to add support for go 1.18 and
> also allow Ludovic to create the branch and rebuild.
>
> Thanks
>
> On Wed, Apr 20, 2022 at 7:36 PM Katherine Cox-Buday <
> cox.katherine.e@gmail.com> wrote:
>
>> >>> Pier-Hugues Pellerin <ph@heykimo.com> writes:
>> >> Ludovic Courtès writes:
>>
>> >>> I am trying to update Go to 1.18, I do have a *working* patch that
>> defines
>> >>> a package that inherits from 1.17 and that adjusts the inputs.
>> >>
>> >> Nice!
>>
>> Yes, thank you! I just found out I need this and came to see if anyone had
>> started on it.
>>
>> >> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
>> both
>> >> versions, and eventually we’ll remove the older one.
>>
>> I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make
>> go-1.17
>> inherit from go-1.18. This means that when it's time to sunset a version,
>> it's
>> a simple delete and not something that cascades through all recent
>> versions.
>>
>> > I think it makes sense, looking at the number of impacted packages and
>> from
>> > my experience working in go, even if the contract is the same,
>> sometimes it
>> > does break on minor.
>>
>> I was wondering if we don't want to start publishing a go-next package
>> like we do with emacs-next? That would allow us to publish the latest
>> version of Go without needing to immediately address building all the
>> packages that depend on it.
>>
>> Kindest regards,
>> --
>> Katherine
>>
>
>
> --
> ph,
> http://heykimo.com
>


-- 
ph,
http://heykimo.com

[-- Attachment #2: Type: text/html, Size: 4556 bytes --]

Re: Updating from Go 1.17 to 1.18

[Katherine Cox-Buday]

Pier-Hugues Pellerin <ph@heykimo.com> writes:

> We should probably also try to mimic how their bootstrap and have the
> following:
>
>    - Bootstrap 1.17 with 1.4
>    - Bootstrap 1.18 with 1.4
>    - Have 1.19 bootstrap with 1.17.
>
> So maybe we should do something like this.
>
> - Add go-1.18 build from 1.4.
> - Add go-next that point to go-1.18
> - Refactor 1.17 package definition that is shared between go-1.18. and
> go-1.17.
> - Move  go to go-1.18  in another branch
> - Remove 1.16?

Thanks for looking into how the Go team will be bootstrapping, and I
agree with your plan. Is there anything I can do to help?

-- 
Katherine

Re: Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Hello Katherine and Ludovic,

I've finally had the time to push the patches[0], my house was hit hard by
sickness.

Concerning having Go 1.18 as the default version, I think it's on Ludovic
side to create a
branch to see where things breaks..

Not sure where the outputs will be but I am sure we will have a few
dependencies to fix
It will be good to work together to fix them.

Thanks



[0] https://issues.guix.gnu.org/55210

On Thu, Apr 21, 2022 at 10:58 AM Katherine Cox-Buday <
cox.katherine.e@gmail.com> wrote:

> Pier-Hugues Pellerin <ph@heykimo.com> writes:
>
> > We should probably also try to mimic how their bootstrap and have the
> > following:
> >
> >    - Bootstrap 1.17 with 1.4
> >    - Bootstrap 1.18 with 1.4
> >    - Have 1.19 bootstrap with 1.17.
> >
> > So maybe we should do something like this.
> >
> > - Add go-1.18 build from 1.4.
> > - Add go-next that point to go-1.18
> > - Refactor 1.17 package definition that is shared between go-1.18. and
> > go-1.17.
> > - Move  go to go-1.18  in another branch
> > - Remove 1.16?
>
> Thanks for looking into how the Go team will be bootstrapping, and I
> agree with your plan. Is there anything I can do to help?
>
> --
> Katherine
>


-- 
ph

[-- Attachment #2: Type: text/html, Size: 2030 bytes --]