[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[宋文武]

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

Hello, this patch handle the '--no-grafts' command line option:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-deploy-Honor-no-grafts.patch --]
[-- Type: text/x-patch, Size: 1263 bytes --]

From a9af4a0404d9cec29ed200c2fa6a6fb160f6babb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong@member.fsf.org>
Date: Sat, 20 Jul 2019 12:45:34 +0800
Subject: [PATCH 1/2] deploy: Honor '--no-grafts'.

* guix/scripts/deploy.scm (guix-deploy): Parameterize '%graft?'.
---
 guix/scripts/deploy.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/deploy.scm b/guix/scripts/deploy.scm
index 978cfb2a81..3acd32eaa7 100644
--- a/guix/scripts/deploy.scm
+++ b/guix/scripts/deploy.scm
@@ -23,6 +23,7 @@
   #:use-module (guix scripts build)
   #:use-module (guix store)
   #:use-module (guix ui)
+  #:use-module (guix grafts)
   #:use-module (ice-9 format)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-37)
@@ -80,5 +81,6 @@ Perform the deployment specified by FILE.\n"))
       (set-build-options-from-command-line store opts)
       (for-each (lambda (machine)
                   (info (G_ "deploying to ~a...") (machine-display-name machine))
-                  (run-with-store store (deploy-machine machine)))
+                  (parameterize ((%graft? (assq-ref opts 'graft?)))
+                    (run-with-store store (deploy-machine machine))))
                 machines))))
-- 
2.19.2


[-- Attachment #3: Type: text/plain, Size: 73 bytes --]



And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0002-deploy-Handle-the-system-command-line-option.patch --]
[-- Type: text/x-patch, Size: 2313 bytes --]

From 192f96a3fa4342765db919006c35cdeb1774b62f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong@member.fsf.org>
Date: Sat, 20 Jul 2019 12:51:45 +0800
Subject: [PATCH 2/2] deploy: Handle the '--system' command line option.

* guix/scripts/deploy.scm (show-help): Add help for '--system'.
(%options): Add '-s' and '--system'.
(guix-deploy): Parameterize %current-system.
---
 guix/scripts/deploy.scm | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/deploy.scm b/guix/scripts/deploy.scm
index 3acd32eaa7..52bba3f3bf 100644
--- a/guix/scripts/deploy.scm
+++ b/guix/scripts/deploy.scm
@@ -23,6 +23,7 @@
   #:use-module (guix scripts build)
   #:use-module (guix store)
   #:use-module (guix ui)
+  #:use-module (guix utils)
   #:use-module (guix grafts)
   #:use-module (ice-9 format)
   #:use-module (srfi srfi-1)
@@ -41,6 +42,8 @@
 (define (show-help)
   (display (G_ "Usage: guix deploy [OPTION] FILE...
 Perform the deployment specified by FILE.\n"))
+  (display (G_ "
+  -s, --system=SYSTEM    attempt to build for SYSTEM--e.g., \"i686-linux\""))
   (show-build-options-help)
   (newline)
   (display (G_ "
@@ -55,10 +58,14 @@ Perform the deployment specified by FILE.\n"))
                  (lambda args
                    (show-help)
                    (exit 0)))
+         (option '(#\s "system") #t #f
+                 (lambda (opt name arg result)
+                   (alist-cons 'system arg
+                               (alist-delete 'system result eq?))))
          %standard-build-options))
 
 (define %default-options
-  '((system . ,(%current-system))
+  `((system . ,(%current-system))
     (substitutes? . #t)
     (build-hook? . #t)
     (graft? . #t)
@@ -81,6 +88,7 @@ Perform the deployment specified by FILE.\n"))
       (set-build-options-from-command-line store opts)
       (for-each (lambda (machine)
                   (info (G_ "deploying to ~a...") (machine-display-name machine))
-                  (parameterize ((%graft? (assq-ref opts 'graft?)))
+                  (parameterize ((%current-system (assq-ref opts 'system))
+                                 (%graft? (assq-ref opts 'graft?)))
                     (run-with-store store (deploy-machine machine))))
                 machines))))
-- 
2.19.2


[-- Attachment #5: Type: text/plain, Size: 246 bytes --]


Or better we can add a 'system' field to the <machine> record, so we can
deploy a list of machines with different 'system'.  Currently a
<machine> has 'system' as a field for the <operating-system>, so where
to put this machine/arch 'system'...

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Jakob L. Kreuze]

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

Hello Wenwu,
iyzsong@member.fsf.org (宋文武) writes:

> Hello, this patch handle the '--no-grafts' command line option:
> ...
> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":

These patches look good to me, thank you!

Ludo, Dave, Chris, any additional comments?

> Or better we can add a 'system' field to the <machine> record, so we
> can deploy a list of machines with different 'system'. Currently a
> <machine> has 'system' as a field for the <operating-system>, so where
> to put this machine/arch 'system'...

Great idea. I think that continuing to call the machine's
<operating-system> 'system' would be confusing if we introduced the
notion of a target architecture, because we use "system" to refer to the
target architecture in the rest of Guix's command-line tools. Maybe it
would make sense to rename the <operating-system> field to 'os' or
something similar, and use the 'system' field to specify the target
architecture instead? Any thoughs?

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Jakob L. Kreuze]

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:

> Great idea. I think that continuing to call the machine's
> <operating-system> 'system' would be confusing if we introduced the
> notion of a target architecture, because we use "system" to refer to
> the target architecture in the rest of Guix's command-line tools.
> Maybe it would make sense to rename the <operating-system> field to
> 'os' or something similar, and use the 'system' field to specify the
> target architecture instead? Any thoughs?

Actually, I had a thought. Why should we make this explicit, when we
could take an implicit approach and identify the target's architecture
with 'remote-eval'? Ideally, we'll be probing the machines anyway to
implement safety checks on the <operating-system> declaration, so why
not just add this to our list of pre-deployment tests?

Regards,
Jakob

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hello Wenwu,
> iyzsong@member.fsf.org (宋文武) writes:
>
>> Hello, this patch handle the '--no-grafts' command line option:
>> ...
>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>
> These patches look good to me, thank you!
>
> Ludo, Dave, Chris, any additional comments?
>
>> Or better we can add a 'system' field to the <machine> record, so we
>> can deploy a list of machines with different 'system'. Currently a
>> <machine> has 'system' as a field for the <operating-system>, so where
>> to put this machine/arch 'system'...
>
> Great idea. I think that continuing to call the machine's
> <operating-system> 'system' would be confusing if we introduced the
> notion of a target architecture, because we use "system" to refer to the
> target architecture in the rest of Guix's command-line tools. Maybe it
> would make sense to rename the <operating-system> field to 'os' or
> something similar, and use the 'system' field to specify the target
> architecture instead? Any thoughs?

I'm fine with a rename to "os"

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> Great idea. I think that continuing to call the machine's
>> <operating-system> 'system' would be confusing if we introduced the
>> notion of a target architecture, because we use "system" to refer to
>> the target architecture in the rest of Guix's command-line tools.
>> Maybe it would make sense to rename the <operating-system> field to
>> 'os' or something similar, and use the 'system' field to specify the
>> target architecture instead? Any thoughs?
>
> Actually, I had a thought. Why should we make this explicit, when we
> could take an implicit approach and identify the target's architecture
> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
> implement safety checks on the <operating-system> declaration, so why
> not just add this to our list of pre-deployment tests?
>
> Regards,
> Jakob

Maybe a good idea... let me think.  Is there any case where we start
taking actions *before* we might probe a machine that we can think of?

How would we also probe it?  Is there a chance of our probing behaving
incorrectly?  That would also be bad, if so.

Another route is to have the user specify what architecture they think
the machine has, and instead the probing is a "safety check"?

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Thompson, David]

On Mon, Jul 22, 2019 at 6:48 PM Jakob L. Kreuze
<zerodaysfordays@sdf.lonestar.org> wrote:
>
> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
> > Great idea. I think that continuing to call the machine's
> > <operating-system> 'system' would be confusing if we introduced the
> > notion of a target architecture, because we use "system" to refer to
> > the target architecture in the rest of Guix's command-line tools.
> > Maybe it would make sense to rename the <operating-system> field to
> > 'os' or something similar, and use the 'system' field to specify the
> > target architecture instead? Any thoughs?
>
> Actually, I had a thought. Why should we make this explicit, when we
> could take an implicit approach and identify the target's architecture
> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
> implement safety checks on the <operating-system> declaration, so why
> not just add this to our list of pre-deployment tests?

I don't see a compelling reason for the architecture to be a part of
the machine data type at this time.  I'd like to avoid such low-level
details if possible because I don't think they will translate well to
more complex methods of deployment.

- Dave

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Jakob L. Kreuze]

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

Hi Chris,

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Maybe a good idea... let me think. Is there any case where we start
> taking actions *before* we might probe a machine that we can think of?
>
> How would we also probe it? Is there a chance of our probing behaving
> incorrectly? That would also be bad, if so.

None that come to mind right now, and if there are any, I don't think
they would be affected by the probing -- aside from doing work that
would get thrown out when the script errors out.

As for the safety of probing, none of the tests I intend on implementing
are effectful. It would be equivalents for 'check-mapped-devices',
'check-file-system-availability', and 'check-initrd-modules', all of
which do little beyond looking at the devices available on the system,
and now a check that would read '%current-system'.

> Another route is to have the user specify what architecture they think
> the machine has, and instead the probing is a "safety check"?

That'd work too, but I feel it's better to avoid putting an unnecessary
burden on the user.

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Jakob L. Kreuze]

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

"Thompson, David" <dthompson2@worcester.edu> writes:

> I don't see a compelling reason for the architecture to be a part of
> the machine data type at this time. I'd like to avoid such low-level
> details if possible because I don't think they will translate well to
> more complex methods of deployment.

A good point. I'll see about having this as an environment-specific
check.

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Ludovic Courtès]

Hello,

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Hello Wenwu,
> iyzsong@member.fsf.org (宋文武) writes:
>
>> Hello, this patch handle the '--no-grafts' command line option:
>> ...
>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>
> These patches look good to me, thank you!
>
> Ludo, Dave, Chris, any additional comments?

Fine with me!

I agree with Dave that we should avoid adding a ‘system-type’ field to
<machine>, at least for now.  Instead, we should just honor
(%current-system).

Thanks,
Ludo’.

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Ricardo Wurmus]

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Jakob L. Kreuze writes:
>
>> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>>
>>> Great idea. I think that continuing to call the machine's
>>> <operating-system> 'system' would be confusing if we introduced the
>>> notion of a target architecture, because we use "system" to refer to
>>> the target architecture in the rest of Guix's command-line tools.
>>> Maybe it would make sense to rename the <operating-system> field to
>>> 'os' or something similar, and use the 'system' field to specify the
>>> target architecture instead? Any thoughs?
>>
>> Actually, I had a thought. Why should we make this explicit, when we
>> could take an implicit approach and identify the target's architecture
>> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
>> implement safety checks on the <operating-system> declaration, so why
>> not just add this to our list of pre-deployment tests?
>>
>> Regards,
>> Jakob
>
> Maybe a good idea... let me think.  Is there any case where we start
> taking actions *before* we might probe a machine that we can think of?

I don’t know if this qualifies, but if “guix deploy” were to *create* a
machine (e.g. on EC2 via the Guile AWS library) it wouldn’t be able to
probe it first.  But in that case we would have full control over what
the target would be, so no probing would be required.

--
Ricardo

[bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system'

[Jakob L. Kreuze]

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

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> I don’t know if this qualifies, but if “guix deploy” were to *create*
> a machine (e.g. on EC2 via the Guile AWS library) it wouldn’t be able
> to probe it first. But in that case we would have full control over
> what the target would be, so no probing would be required.

Ah, good point. I suppose didn't think about this all the way through in
my response -- we wouldn't be able to probe an unprovisioned machine.
But your point gives me even more confidence in the decision to deduce
target architecture at runtime and have that as an environment-specific
check.

Thanks for chiming in!

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36738: [PATCH] guix deploy: Support '--no-grafts' and '--system'

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>
>> Hello Wenwu,
>> iyzsong@member.fsf.org (宋文武) writes:
>>
>>> Hello, this patch handle the '--no-grafts' command line option:
>>> ...
>>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>>
>> These patches look good to me, thank you!
>>
>> Ludo, Dave, Chris, any additional comments?
>
> Fine with me!
>
> I agree with Dave that we should avoid adding a ‘system-type’ field to
> <machine>, at least for now.  Instead, we should just honor
> (%current-system).
>
> Thanks,
> Ludo’.

Pushed, thanks for the reviews!