The usability of Guix configurations

The usability of Guix configurations

[myglc2]

My system recently broke when I did an upgrade. I reported what I
thought was a bug (bug#29072) but it turned out that, because qemu
package code had been moved, my system configuration had become broken
;-(

Confronted with my situation, helpful developers said "The package code
was moved in commit xxx" (Leo) and "maybe you have a mistake in your
config (Efraim)."

Once I understood what had happened I wondered, "Gee, I have been using
guix for 18 months so why didn't I figure this out myself." ;-)

But a less committed user might say, "Wow, Guix breaks at random, error
messages are hard to understand, and support is difficult."  :-(

ISTM this raises issues and questions about Guix configuration
usability:

Guix config errors are reported as raw scheme errors which are not
user-friendly, except, perhaps, to guile users ;-) Could we improve this
situation by adding config troubleshooting guidance to the doc?

Guix config errors consume meaningful amounts of user and support
effort. I say this because a) it took quite a few iterations to figure
out what was wrong in my situation, and b) google search for '"no code
for module" guix' finds 613 hits, which will no doubt grow linearly with
number of Guix users unless something is done. So I wonder, could an
error handler that translates into more user-friendly terms reduce user
frustration, increase the rate of user self help, reduce support load,
and effectively pay for itself?

Are the current Guix config errors usable by the average GNU/Linux
distribution user? If not, don't they need to be improved before we call
it 1.0?
        
Does this mean that package code must not be moved after 1.0?

Finally: Should I close bug#29072? ;-)

bug#29072: The usability of Guix configurations

[Leo Famulari]

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

On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
> My system recently broke when I did an upgrade. I reported what I
> thought was a bug (bug#29072) but it turned out that, because qemu
> package code had been moved, my system configuration had become broken
> ;-(
> 
> Confronted with my situation, helpful developers said "The package code
> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
> config (Efraim)."

I'm sorry that my comment was not enough on its own!

> Once I understood what had happened I wondered, "Gee, I have been using
> guix for 18 months so why didn't I figure this out myself." ;-)
> 
> But a less committed user might say, "Wow, Guix breaks at random, error
> messages are hard to understand, and support is difficult."  :-(

Good point.

> ISTM this raises issues and questions about Guix configuration
> usability:

Indeed.

> Guix config errors are reported as raw scheme errors which are not
> user-friendly, except, perhaps, to guile users ;-) Could we improve this
> situation by adding config troubleshooting guidance to the doc?

Yes, we do try to add helpful error messages, although obviously there
is a lot more work to be done.

As far as I can tell, the issue was related to the fact that you are
using Guix by building it from source and re-using the same build
directory, which may contain stale compiled .go files. In this case,
there was a leftover qemu.go, which shadowed the correct file,
virtualization.go.

This is a useful development technique but not how Guix is supposed to
be deployed and updated. `guix pull && guix package --upgrade` is still
what we recommend and support.

If you want to deploy Guix by building it "by hand", I recommend using a
fresh Git checkout and directory each time you build it. That way, you
can be sure to avoid this class of error (stale module references in
leftover .go files), which is well-known to the seasoned Guix developers
but totally confounding for everyone else.

> Guix config errors consume meaningful amounts of user and support
> effort. I say this because a) it took quite a few iterations to figure
> out what was wrong in my situation, and b) google search for '"no code
> for module" guix' finds 613 hits, which will no doubt grow linearly with
> number of Guix users unless something is done. So I wonder, could an
> error handler that translates into more user-friendly terms reduce user
> frustration, increase the rate of user self help, reduce support load,
> and effectively pay for itself?

That would be awesome!

> Are the current Guix config errors usable by the average GNU/Linux
> distribution user? If not, don't they need to be improved before we call
> it 1.0?

Based on how much time it's possible to spend on IRC helping people, I'd
say there is lots of room for improvement in this area.

> Does this mean that package code must not be moved after 1.0?

A couple thoughts... it would be nice if the GuixSD configuration
example templates used a filename agnostic method of resolving module
imports. I'm not a strong enough Schemer to evaluate the situation or
suggest a solution, but I think that the filenames should not be
relevant at that level. Perhaps one could use
'specification->package+output',
as demonstrated in the documentation of package manifests:

https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

> Finally: Should I close bug#29072? ;-)

The problem of the missing QEMU patch is resolved. The broader issue of
confusing error messages could be continued here, or elsewhere. It's up
to you :)

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

Re: The usability of Guix configurations

[Leo Famulari]

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

On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
> My system recently broke when I did an upgrade. I reported what I
> thought was a bug (bug#29072) but it turned out that, because qemu
> package code had been moved, my system configuration had become broken
> ;-(
> 
> Confronted with my situation, helpful developers said "The package code
> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
> config (Efraim)."

I'm sorry that my comment was not enough on its own!

> Once I understood what had happened I wondered, "Gee, I have been using
> guix for 18 months so why didn't I figure this out myself." ;-)
> 
> But a less committed user might say, "Wow, Guix breaks at random, error
> messages are hard to understand, and support is difficult."  :-(

Good point.

> ISTM this raises issues and questions about Guix configuration
> usability:

Indeed.

> Guix config errors are reported as raw scheme errors which are not
> user-friendly, except, perhaps, to guile users ;-) Could we improve this
> situation by adding config troubleshooting guidance to the doc?

Yes, we do try to add helpful error messages, although obviously there
is a lot more work to be done.

As far as I can tell, the issue was related to the fact that you are
using Guix by building it from source and re-using the same build
directory, which may contain stale compiled .go files. In this case,
there was a leftover qemu.go, which shadowed the correct file,
virtualization.go.

This is a useful development technique but not how Guix is supposed to
be deployed and updated. `guix pull && guix package --upgrade` is still
what we recommend and support.

If you want to deploy Guix by building it "by hand", I recommend using a
fresh Git checkout and directory each time you build it. That way, you
can be sure to avoid this class of error (stale module references in
leftover .go files), which is well-known to the seasoned Guix developers
but totally confounding for everyone else.

> Guix config errors consume meaningful amounts of user and support
> effort. I say this because a) it took quite a few iterations to figure
> out what was wrong in my situation, and b) google search for '"no code
> for module" guix' finds 613 hits, which will no doubt grow linearly with
> number of Guix users unless something is done. So I wonder, could an
> error handler that translates into more user-friendly terms reduce user
> frustration, increase the rate of user self help, reduce support load,
> and effectively pay for itself?

That would be awesome!

> Are the current Guix config errors usable by the average GNU/Linux
> distribution user? If not, don't they need to be improved before we call
> it 1.0?

Based on how much time it's possible to spend on IRC helping people, I'd
say there is lots of room for improvement in this area.

> Does this mean that package code must not be moved after 1.0?

A couple thoughts... it would be nice if the GuixSD configuration
example templates used a filename agnostic method of resolving module
imports. I'm not a strong enough Schemer to evaluate the situation or
suggest a solution, but I think that the filenames should not be
relevant at that level. Perhaps one could use
'specification->package+output',
as demonstrated in the documentation of package manifests:

https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

> Finally: Should I close bug#29072? ;-)

The problem of the missing QEMU patch is resolved. The broader issue of
confusing error messages could be continued here, or elsewhere. It's up
to you :)

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

bug#29072: The usability of Guix configurations

[myglc2]

Please note: these replies separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 22:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>>
>> Confronted with my situation, helpful developers said "The package code
>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>> config (Efraim)."
>
> I'm sorry that my comment was not enough on its own!

Hey Leo,

Please understand that don't mean this as a complaint your reply, which
was helpful and I was very happy to receive.

I am just trying to step back and think about the bigger picture.

Re: The usability of Guix configurations

[myglc2]

Please note: these replies separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 22:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>>
>> Confronted with my situation, helpful developers said "The package code
>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>> config (Efraim)."
>
> I'm sorry that my comment was not enough on its own!

Hey Leo,

Please understand that don't mean this as a complaint your reply, which
was helpful and I was very happy to receive.

I am just trying to step back and think about the bigger picture.

Re: The usability of Guix configurations

[myglc2]

Please note: these replies are separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
[...]
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.

I didn't mean this point critically. Rather as a statement of fact. When
I said ...

>> Could we improve this situation by adding config troubleshooting
>> guidance to the doc?

... I was thinking something like ...

vvvvvvvvvvvvvvvvvv

Troubleshooting your config file:

If you get an error like:

ice-9/boot-9.scm:[...] no code for module (gnu packages <package name>)

You have either specified a package name that does not exist, or your
(use-package-modules <package module names>) does not contain the name
of a package module that contains the definition of <package name>.

You can determine which, if any, module contains a package definition by
yada yada yada

^^^^^^^^^^^^^^^^^^

... thinking that then there would be a search hit in the doc for 'no
code for module' which might enable some users to understand what they
are doing wrong.

WDYT? - George

Re: The usability of Guix configurations

[julien lepiller]

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

Le 2017-11-07 02:56, myglc2 a écrit :
> Please note: these replies are separated by topics in an effort to make 
> the
> threads more topical ...
> 
> On 11/06/2017 at 17:16 Leo Famulari writes:
> 
>> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
> [...]
>>> Guix config errors are reported as raw scheme errors which are not
>>> user-friendly, except, perhaps, to guile users ;-) Could we improve 
>>> this
>>> situation by adding config troubleshooting guidance to the doc?
>> 
>> Yes, we do try to add helpful error messages, although obviously there
>> is a lot more work to be done.
> 
> I didn't mean this point critically. Rather as a statement of fact. 
> When
> I said ...
> 
>>> Could we improve this situation by adding config troubleshooting
>>> guidance to the doc?
> 
> ... I was thinking something like ...
> 
> vvvvvvvvvvvvvvvvvv
> 
> Troubleshooting your config file:
> 
> If you get an error like:
> 
> ice-9/boot-9.scm:[...] no code for module (gnu packages <package name>)
> 
> You have either specified a package name that does not exist, or your
> (use-package-modules <package module names>) does not contain the name
> of a package module that contains the definition of <package name>.
> 
> You can determine which, if any, module contains a package definition 
> by
> yada yada yada
> 
> ^^^^^^^^^^^^^^^^^^
> 
> ... thinking that then there would be a search hit in the doc for 'no
> code for module' which might enable some users to understand what they
> are doing wrong.
> 
> WDYT? - George

Hi George,

Since we encourage users to use use-package-modules etc, I think it's 
better
to catch this error and explain it to users as soon as it happens. It's 
more
friendly for users than a troubleshooting section in the manual. This 
patch
would print:


Package module "abc" does not exist.
ERROR: In procedure scm-error:
ERROR: check "use-package-modules" line in your configuration.


If you try to use something like (use-package-modules linux abc), and
similar messages for services and system modules.

WDYT?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Catch-use-modules-errors-in-configuration.patch --]
[-- Type: text/x-diff; name=0001-Catch-use-modules-errors-in-configuration.patch, Size: 1843 bytes --]

From c47acf0508358ff160719f728844a82a5db07d05 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Tue, 7 Nov 2017 11:46:34 +0100
Subject: [PATCH] Catch use-modules errors in configuration.

* gnu.scm (use-package-modules, use-service-modules, use-system-modules):
Catch use-modules errors and show a small explanation about it.
---
 gnu.scm | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..c269b2ab0 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -53,12 +53,32 @@
               %public-modules)))
 
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu packages module)))
+           (lambda _
+             (format #t "Package module \"~a\" does not exist.\n"
+                     (symbol->string 'module))
+             (error "check \"use-package-modules\" line in your configuration.")
+    ...))))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu services module)))
+           (lambda _
+             (format #t "Service module \"~a\" does not exist.\n"
+                     (symbol->string 'module))
+             (error "check \"use-package-services\" line in your configuration.")
+    ...))))
+
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu system module)))
+           (lambda _
+             (format #t "System module \"~a\" does not exist.\n"
+                     (symbol->string 'module))
+             (error "check \"use-system-modules\" line in your configuration.")
+    ...))))
+
 
 ;;; gnu.scm ends here
-- 
2.15.0

Re: The usability of Guix configurations

[Hartmut Goebel]

Am 07.11.2017 um 12:05 schrieb julien lepiller:
> Since we encourage users to use use-package-modules etc, I think it's
> better
> to catch this error and explain it to users as soon as it happens.
> It's more
> friendly for users than a troubleshooting section in the manual.

+1
Thanks for proposing a patch so quickly!

> Package module "abc" does not exist.
> ERROR: In procedure scm-error:
> ERROR: check "use-package-modules" line in your configuration.

For me this looks confusing: The actual error message is not prefixed by
"ERROR:". Also (nitpicking) the explanation could by a bit more verbose.
Like this:

ERROR: In procedure scm-error:
ERROR: Package module "abc" does not exist.
ERROR: Please check the "use-package-modules" line in your configuration.

It would even be better is the fist line would not refer to "procedure
scm-error", but to the config actually processed (and even the line in
there). But nevertheless this patch is a big improvement already.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: The usability of Guix configurations

[julien lepiller]

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

Le 2017-11-07 13:52, Hartmut Goebel a écrit :
> Am 07.11.2017 um 12:05 schrieb julien lepiller:
>> Since we encourage users to use use-package-modules etc, I think it's
>> better
>> to catch this error and explain it to users as soon as it happens.
>> It's more
>> friendly for users than a troubleshooting section in the manual.
> 
> +1
> Thanks for proposing a patch so quickly!
> 
>> Package module "abc" does not exist.
>> ERROR: In procedure scm-error:
>> ERROR: check "use-package-modules" line in your configuration.
> 
> For me this looks confusing: The actual error message is not prefixed 
> by
> "ERROR:". Also (nitpicking) the explanation could by a bit more 
> verbose.
> Like this:
> 
> ERROR: In procedure scm-error:
> ERROR: Package module "abc" does not exist.
> ERROR: Please check the "use-package-modules" line in your 
> configuration.
> 
> It would even be better is the fist line would not refer to "procedure
> scm-error", but to the config actually processed (and even the line in
> there). But nevertheless this patch is a big improvement already.

This new version outputs something like this :


guix system: error: failed to load 'vm-image.tmpl':
vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not 
exist.
Check the "use-package-modules" line in your configuration.


Previously I tested in in the REPL, hence no filename. This time I
modified vm-image.tmpl to add an "abc" package, and ran
"guix system vm vm-image.tmpl".

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Catch-use-modules-errors-in-configuration.patch --]
[-- Type: text/x-diff; name=0001-Catch-use-modules-errors-in-configuration.patch, Size: 1767 bytes --]

From 334852e5cd7f526c93b2ad7061bd56c0326d136f Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Tue, 7 Nov 2017 11:46:34 +0100
Subject: [PATCH] Catch use-modules errors in configuration.

* gnu.scm (use-package-modules, use-service-modules, use-system-modules):
Catch use-modules errors and show a small explanation about it.
---
 gnu.scm | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..3de04fd8a 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -52,13 +52,32 @@
                   (module-use! i (resolve-interface m))))
               %public-modules)))
 
+(define (import-error type module syntax)
+  (error (string-append
+           type " module \"" module "\" does not exist.\n"
+           "Check the \"" syntax "\" line in your configuration.")))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu packages module)))
+           (lambda _
+             (import-error "Package" (symbol->string 'module) "use-package-modules")))
+    ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu services module)))
+           (lambda _
+             (import-error "Service" (symbol->string 'module) "use-service-modules")))
+    ...))
+
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu system module)))
+           (lambda _
+             (import-error "System" (symbol->string 'module) "use-system-modules")))
+    ...))
+
 
 ;;; gnu.scm ends here
-- 
2.13.6

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 14:13 julien lepiller writes:

> Le 2017-11-07 13:52, Hartmut Goebel a écrit :
>> Am 07.11.2017 um 12:05 schrieb julien lepiller:
>>> Since we encourage users to use use-package-modules etc, I think it's
>>> better
>>> to catch this error and explain it to users as soon as it happens.
>>> It's more
>>> friendly for users than a troubleshooting section in the manual.
>>
>> +1
>> Thanks for proposing a patch so quickly!
>>
>>> Package module "abc" does not exist.
>>> ERROR: In procedure scm-error:
>>> ERROR: check "use-package-modules" line in your configuration.
>>
>> For me this looks confusing: The actual error message is not
>> prefixed by
>> "ERROR:". Also (nitpicking) the explanation could by a bit more
>> verbose.
>> Like this:
>>
>> ERROR: In procedure scm-error:
>> ERROR: Package module "abc" does not exist.
>> ERROR: Please check the "use-package-modules" line in your
>> configuration.
>>
>> It would even be better is the fist line would not refer to "procedure
>> scm-error", but to the config actually processed (and even the line in
>> there). But nevertheless this patch is a big improvement already.
>
> This new version outputs something like this :
>
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
> exist.
> Check the "use-package-modules" line in your configuration.

Thanks Julien, I tried the patch and it works for me. I think it is a
great improvement.

Small suggestion: is it feasible for the last line to read:

Please add a module containing "abc" to the "use-package-modules" line in your configuration.

TIA - George

Re: The usability of Guix configurations

[julien lepiller]

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

Le 2017-11-07 15:11, myglc2 a écrit :
> On 11/07/2017 at 14:13 julien lepiller writes:
>> 
>> This new version outputs something like this :
>> 
>> 
>> guix system: error: failed to load 'vm-image.tmpl':
>> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
>> exist.
>> Check the "use-package-modules" line in your configuration.
> 
> Thanks Julien, I tried the patch and it works for me. I think it is a
> great improvement.
> 
> Small suggestion: is it feasible for the last line to read:
> 
> Please add a module containing "abc" to the "use-package-modules" line
> in your configuration.

Wouldn't that be confusing though?

Maybe you're confused because modules have the same name as some 
packages,
but there is no relation between a package name and its module in 
general.
In (use-package-modules abc), abc refers to a file named 
'gnu/packages/abc.go'
and the error happens when this file doesn't exist.

Maybe that last line could be a hint as to how to find the correct 
module, though,
such as:

guix system: error: failed to load 'vm-image.tmpl':
vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not 
exist.
Check the "use-package-modules" line in your configuration.
Hint: You may use `guix package -s foo` to search for foo's location.
Hint: If you get the line "location: gnu/packages/ssh.scm:174:2",
Hint: you want to add ssh in use-package-modules.

And similarly with services:

guix system: error: failed to load 'vm-image.tmpl':
vm-image.tmpl:7:0: vm-image.tmpl:7:0: Service module "abc" does not 
exist.
Check the "use-service-modules" line in your configuration.
Hint: You may use `guix system search foo` to search for foo's location.
Hint: If you get the line "location: gnu/services/ssh.scm:188:2",
Hint: you want to add ssh in use-service-modules.

Maybe that's too much?

> 
> TIA - George

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Catch-use-modules-errors-in-configuration.patch --]
[-- Type: text/x-diff; name=0001-Catch-use-modules-errors-in-configuration.patch, Size: 2488 bytes --]

From 3efdec7eb56d8ac52b6af00b0c3046456054fe41 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Tue, 7 Nov 2017 11:46:34 +0100
Subject: [PATCH] Catch use-modules errors in configuration.

* gnu.scm (use-package-modules, use-service-modules, use-system-modules):
Catch use-modules errors and show a small explanation about it.
---
 gnu.scm | 40 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..64c752915 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -52,13 +52,47 @@
                   (module-use! i (resolve-interface m))))
               %public-modules)))
 
+(define (import-error type module syntax)
+  (define package-hint
+    (string-append
+      "Hint: You may use `guix package -s foo` to search for foo's location.\n"
+      "Hint: If you get the line \"location: gnu/packages/ssh.scm:174:2\",\n"
+      "Hint: you want to add ssh in use-package-modules."))
+  (define service-hint
+    (string-append
+      "Hint: You may use `guix system search foo` to search for foo's location.\n"
+      "Hint: If you get the line \"location: gnu/services/ssh.scm:188:2\",\n"
+      "Hint: you want to add ssh in use-service-modules."))
+  (error (string-append
+           type " module \"" module "\" does not exist.\n"
+           "Check the \"" syntax "\" line in your configuration.\n"
+           (if (equal? type "Package")
+               package-hint
+               (if (equal? type "Service")
+                   service-hint
+                   "")))))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu packages module)))
+           (lambda _
+             (import-error "Package" (symbol->string 'module) "use-package-modules")))
+    ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu services module)))
+           (lambda _
+             (import-error "Service" (symbol->string 'module) "use-service-modules")))
+    ...))
+
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu system module)))
+           (lambda _
+             (import-error "System" (symbol->string 'module) "use-system-modules")))
+    ...))
+
 
 ;;; gnu.scm ends here
-- 
2.13.6

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 15:52 julien lepiller writes:

> Le 2017-11-07 15:11, myglc2 a écrit :
>> On 11/07/2017 at 14:13 julien lepiller writes:
>>>
>>> This new version outputs something like this :
>>>
>>>
>>> guix system: error: failed to load 'vm-image.tmpl':
>>> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
>>> exist.
>>> Check the "use-package-modules" line in your configuration.
>>
>> Thanks Julien, I tried the patch and it works for me. I think it is a
>> great improvement.
>>
>> Small suggestion: is it feasible for the last line to read:
>>
>> Please add a module containing "abc" to the "use-package-modules" line
>> in your configuration.
>
> Wouldn't that be confusing though?
>
> Maybe you're confused because modules have the same name as some
> packages,
> but there is no relation between a package name and its module in
> general.
> In (use-package-modules abc), abc refers to a file named
> 'gnu/packages/abc.go'
> and the error happens when this file doesn't exist.
>
> Maybe that last line could be a hint as to how to find the correct
> module, though,
> such as:
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
> exist.
> Check the "use-package-modules" line in your configuration.
> Hint: You may use `guix package -s foo` to search for foo's location.
> Hint: If you get the line "location: gnu/packages/ssh.scm:174:2",
> Hint: you want to add ssh in use-package-modules.
>
> And similarly with services:
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:7:0: vm-image.tmpl:7:0: Service module "abc" does not
> exist.
> Check the "use-service-modules" line in your configuration.
> Hint: You may use `guix system search foo` to search for foo's location.
> Hint: If you get the line "location: gnu/services/ssh.scm:188:2",
> Hint: you want to add ssh in use-service-modules.
>
> Maybe that's too much?

Not for me. Looks great! Just a couple minor suggestions:

1) How about narrowing search to locations like this:

Hint: You may use `guix package --show=foo | grep location` to search for foo's location.

2) I think you mean to say "foo" where you say "ssh" in the last two HINTs

[PATCH] Re: The usability of Guix configurations

[julien lepiller]

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

Le 2017-11-07 16:59, myglc2 a écrit :
> On 11/07/2017 at 15:52 julien lepiller writes:
>> 
>> Maybe that's too much?
> 
> Not for me. Looks great! Just a couple minor suggestions:
> 
> 1) How about narrowing search to locations like this:
> 
> Hint: You may use `guix package --show=foo | grep location` to search
> for foo's location.

Oh, I didn't know this option, good idea, thanks :D

> 
> 2) I think you mean to say "foo" where you say "ssh" in the last two 
> HINTs

You're right, though I prefer to use "bar" to show there is no relation 
between
the package name and its module.

I added "[PATCH]" to the subject to get others look at this message. I 
plan to
push it in a few days unless it gets more comments. If an experienced 
schemer
could look at that, I'm sure the coding style could be improved a lot ;)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Catch-use-modules-errors-in-configuration.patch --]
[-- Type: text/x-diff; name=0001-Catch-use-modules-errors-in-configuration.patch, Size: 2844 bytes --]

From e092725c05625f1b6c5705177b3f080471611e85 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Tue, 7 Nov 2017 11:46:34 +0100
Subject: [PATCH] Catch use-modules errors in configuration.

* gnu.scm (use-package-modules, use-service-modules, use-system-modules):
Catch use-modules errors and show a small explanation about it.
---
 gnu.scm | 42 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..1ae5f2d1d 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2014, 2015, 2016 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2015 Joshua S. Grant <jgrant@parenthetical.io>
 ;;; Copyright © 2017 Mathieu Othacehe <m.othacehe@gmail.com>
+;;; Copyright © 2017 Julien Lepiller <julien@lepiller.eu>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -52,13 +53,48 @@
                   (module-use! i (resolve-interface m))))
               %public-modules)))
 
+(define (import-error type module syntax)
+  (define package-hint
+    (string-append
+      "Hint: You may use `guix package --show=foo | grep location` to search\n"
+      "Hint: for foo's location.\n"
+      "Hint: If you get the line \"location: gnu/packages/bar.scm:174:2\",\n"
+      "Hint: you want to add bar in use-package-modules."))
+  (define service-hint
+    (string-append
+      "Hint: You may use `guix system search foo` to search for foo's location.\n"
+      "Hint: If you get the line \"location: gnu/services/bar.scm:188:2\",\n"
+      "Hint: you want to add bar in use-service-modules."))
+  (error (string-append
+           type " module \"" module "\" does not exist.\n"
+           "Check the \"" syntax "\" line in your configuration.\n"
+           (if (equal? type "Package")
+               package-hint
+               (if (equal? type "Service")
+                   service-hint
+                   "")))))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu packages module)))
+           (lambda _
+             (import-error "Package" (symbol->string 'module) "use-package-modules")))
+    ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu services module)))
+           (lambda _
+             (import-error "Service" (symbol->string 'module) "use-service-modules")))
+    ...))
+
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (begin
+    (catch #t (lambda () (use-modules (gnu system module)))
+           (lambda _
+             (import-error "System" (symbol->string 'module) "use-system-modules")))
+    ...))
+
 
 ;;; gnu.scm ends here
-- 
2.13.6

Re: [PATCH] Re: The usability of Guix configurations

[Julien Lepiller]

Le Tue, 07 Nov 2017 13:06:41 -0500,
myglc2 <myglc2@gmail.com> a écrit :

> On 11/07/2017 at 17:25 julien lepiller writes:
> 
> > Le 2017-11-07 16:59, myglc2 a écrit :  
> >> On 11/07/2017 at 15:52 julien lepiller writes:  
> >>>
> >>> Maybe that's too much?  
> >>
> >> Not for me. Looks great! Just a couple minor suggestions:
> >>
> >> 1) How about narrowing search to locations like this:
> >>
> >> Hint: You may use `guix package --show=foo | grep location` to
> >> search for foo's location.  
> >
> > Oh, I didn't know this option, good idea, thanks :D
> >  
> >>
> >> 2) I think you mean to say "foo" where you say "ssh" in the last
> >> two HINTs  
> >
> > You're right, though I prefer to use "bar" to show there is no
> > relation between
> > the package name and its module.
> >
> > I added "[PATCH]" to the subject to get others look at this
> > message. I plan to
> > push it in a few days unless it gets more comments. If an
> > experienced schemer
> > could look at that, I'm sure the coding style could be improved a
> > lot ;)  
> 
> Hmm, I think you  introduced a bug in your last changes because I now
> get ...
> 
> root@g1 ~/con/17# guix system build sys.scm
> guix system: error: failed to load 'sys.scm':
> /root/con/17/sys.scm:79:19: /root/con/17/sys.scm:79:19: In procedure
> module-lookup: Unbound variable: x11-forwarding?
> 
> ... on the attached sys.scm
> 

I don't understand the error... When trying to do (service
openssh-service-type (openssh-configuration))), I get

sys.scm:86:41: sys.scm:86:41: Wrong type to apply: #<syntax-transformer
openssh-configuration>

and I can't reproduce from the REPL... Why don't we get the same error
with agetty-configuration (removing the openssh service does not make
any error)?

I was too optimistic I guess :)

Re: [PATCH] Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 22:27 Julien Lepiller writes:

> Le Tue, 07 Nov 2017 13:06:41 -0500,
> myglc2 <myglc2@gmail.com> a écrit :
>
>> On 11/07/2017 at 17:25 julien lepiller writes:
>> 
>> > Le 2017-11-07 16:59, myglc2 a écrit :  
>> >> On 11/07/2017 at 15:52 julien lepiller writes:  
>> >>>
>> >>> Maybe that's too much?  
>> >>
>> >> Not for me. Looks great! Just a couple minor suggestions:
>> >>
>> >> 1) How about narrowing search to locations like this:
>> >>
>> >> Hint: You may use `guix package --show=foo | grep location` to
>> >> search for foo's location.  
>> >
>> > Oh, I didn't know this option, good idea, thanks :D
>> >  
>> >>
>> >> 2) I think you mean to say "foo" where you say "ssh" in the last
>> >> two HINTs  
>> >
>> > You're right, though I prefer to use "bar" to show there is no
>> > relation between
>> > the package name and its module.
>> >
>> > I added "[PATCH]" to the subject to get others look at this
>> > message. I plan to
>> > push it in a few days unless it gets more comments. If an
>> > experienced schemer
>> > could look at that, I'm sure the coding style could be improved a
>> > lot ;)  
>> 
>> Hmm, I think you  introduced a bug in your last changes because I now
>> get ...
>> 
>> root@g1 ~/con/17# guix system build sys.scm
>> guix system: error: failed to load 'sys.scm':
>> /root/con/17/sys.scm:79:19: /root/con/17/sys.scm:79:19: In procedure
>> module-lookup: Unbound variable: x11-forwarding?
>> 
>> ... on the attached sys.scm
>> 
>
> I don't understand the error... When trying to do (service
> openssh-service-type (openssh-configuration))), I get
>
> sys.scm:86:41: sys.scm:86:41: Wrong type to apply: #<syntax-transformer
> openssh-configuration>
>
> and I can't reproduce from the REPL... Why don't we get the same error
> with agetty-configuration (removing the openssh service does not make
> any error)?
>
> I was too optimistic I guess :)

Dunno. I double checked. I definitely get 'module-lookup: Unbound
variable: x11-forwarding?'  here with your latest patch.

I am happy to test something if that will help.

Just to be clear, I tested the patch that you sent immediately before
and _it worked great._ Did you diff these two patches?

> I was too optimistic I guess :)

This is not a problem for because, in my experience, there is usually
too little optimism ;)

It seems like I broke the thread. Sorry about that. - George

Reporting module errors

[Ludovic Courtès]

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

Hello!

You’re too fast!  :-)

julien lepiller <julien@lepiller.eu> skribis:

> +(define (import-error type module syntax)
> +  (define package-hint
> +    (string-append
> +      "Hint: You may use `guix package --show=foo | grep location` to search\n"
> +      "Hint: for foo's location.\n"
> +      "Hint: If you get the line \"location: gnu/packages/bar.scm:174:2\",\n"
> +      "Hint: you want to add bar in use-package-modules."))
> +  (define service-hint
> +    (string-append
> +      "Hint: You may use `guix system search foo` to search for foo's location.\n"
> +      "Hint: If you get the line \"location: gnu/services/bar.scm:188:2\",\n"
> +      "Hint: you want to add bar in use-service-modules."))
> +  (error (string-append
> +           type " module \"" module "\" does not exist.\n"
> +           "Check the \"" syntax "\" line in your configuration.\n"
> +           (if (equal? type "Package")
> +               package-hint
> +               (if (equal? type "Service")
> +                   service-hint
> +                   "")))))
> +
>  (define-syntax-rule (use-package-modules module ...)
> -  (use-modules (gnu packages module) ...))
> +  (begin
> +    (catch #t (lambda () (use-modules (gnu packages module)))
> +           (lambda _
> +             (import-error "Package" (symbol->string 'module) "use-package-modules")))
> +    ...))

That’s a great suggestion!

I’d propose a variant of it, see below.  With this, one gets a message
like:

  /tmp/config.scm:6:0: module (gnu packages foobar) could not be found

where line 6 is:

  (use-package-modules foobar)

How does that sound?

It lacks the hints that you were proposing, which isn’t great, but I
think we’d need to provide a homogeneous and internationalized API in
(guix ui) if we are to display hints.  But overall I like the idea of
providing hints somehow.

Perhaps we could simply introduce another condition type for hints as a
first step, similar to ‘&message’?

Speaking of hints, we should have something that suggests a module name
based on the Levenshtein distance with available modules.  :-)

Thanks,
Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 5842 bytes --]

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..6dde968f1 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015, 2016 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2015 Joshua S. Grant <jgrant@parenthetical.io>
 ;;; Copyright © 2017 Mathieu Othacehe <m.othacehe@gmail.com>
 ;;;
@@ -19,6 +19,10 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu)
+  #:use-module (guix utils)
+  #:use-module (srfi srfi-34)
+  #:use-module (srfi srfi-35)
+  #:use-module (ice-9 match)
   #:export (use-package-modules
             use-service-modules
             use-system-modules))
@@ -52,13 +56,46 @@
                   (module-use! i (resolve-interface m))))
               %public-modules)))
 
+(define (%try-use-modules modules location)
+  "Attempt to load all of MODULES.  Report errors as coming from LOCATION, a
+source property alist."
+  (define (location->string loc)
+    (match loc
+      (#f "")
+      (($ <location> file line column)
+       (format #f "~a:~a:~a: " file line column))))
+
+  (for-each (lambda (module)
+              (catch 'misc-error
+                (lambda ()
+                  (process-use-modules `((,module))))
+                (lambda _
+                  (raise (condition
+                          (&message
+                           ;; TODO: Suggest a module with a similar name.
+                           (message
+                            (let-syntax ((G_ (syntax-rules ()
+                                               ((_ str) str))))
+                              (format #f
+                                      (G_ "module ~a could not be found~%")
+                                      module))))
+                          (&error-location
+                           (location location)))))))
+            modules))
+
+(define-syntax-rule (try-use-modules modules ...)
+  (eval-when (expand load eval)
+    (%try-use-modules '(modules ...)
+                      (source-properties->location
+                       (current-source-location)))))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (try-use-modules (gnu packages module) ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (try-use-modules (gnu services module) ...))
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (try-use-modules (gnu system module) ...))
 
 ;;; gnu.scm ends here
diff --git a/guix/ui.scm b/guix/ui.scm
index 3c8734a7d..cd3a44fb4 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -272,9 +272,15 @@ ARGS is the list of arguments received by the 'throw' handler."
                (location->string loc) message)))
     (('srfi-34 obj)
      (if (message-condition? obj)
-         (report-error (G_ "~a~%")
-                       (gettext (condition-message obj)
-                                %gettext-domain))
+         (if (error-location? obj)
+             (format (current-error-port)
+                     (G_ "~a: ~a~%")
+                     (location->string (error-location obj))
+                     (gettext (condition-message obj)
+                              %gettext-domain))
+             (report-error (G_ "~a~%")
+                           (gettext (condition-message obj)
+                                    %gettext-domain)))
          (report-error (G_ "exception thrown: ~s~%") obj)))
     ((error args ...)
      (report-error (G_ "failed to load '~a':~%") file)
@@ -538,6 +544,11 @@ interpreted."
 directories:~{ ~a~}~%")
                     (file-search-error-file-name c)
                     (file-search-error-search-path c)))
+            ((and (error-location? c) (message-condition? c))
+             (format (current-error-port)
+                     (G_ "~a: ~a~%")
+                     (location->string (error-location c))
+                     (gettext (condition-message c) %gettext-domain)))
             ((message-condition? c)
              ;; Normally '&message' error conditions have an i18n'd message.
              (leave (G_ "~a~%")
diff --git a/guix/utils.scm b/guix/utils.scm
index eb1ec29b3..e25e2299e 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -28,6 +28,7 @@
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
+  #:use-module (srfi srfi-35)
   #:use-module (srfi srfi-39)
   #:use-module (ice-9 binary-ports)
   #:autoload   (rnrs io ports) (make-custom-binary-input-port)
@@ -60,6 +61,10 @@
             source-properties->location
             location->source-properties
 
+            &error-location
+            error-location?
+            error-location
+
             nix-system->gnu-triplet
             gnu-triplet->nix-system
             %current-system
@@ -750,6 +755,10 @@ a location object."
     (column   . ,(location-column loc))
     (filename . ,(location-file loc))))
 
+(define-condition-type &error-location &error
+  error-location?
+  (location  error-location))                     ;<location>
+
 ;;; Local Variables:
 ;;; eval: (put 'call-with-progress-reporter 'scheme-indent-function 1)
 ;;; End:
diff --git a/po/guix/POTFILES.in b/po/guix/POTFILES.in
index e3f767cc6..6510b99e8 100644
--- a/po/guix/POTFILES.in
+++ b/po/guix/POTFILES.in
@@ -1,5 +1,6 @@
 # List of source files which contain translatable strings.
 # This should be source files of the various tools, and not package modules.
+gnu.scm
 gnu/packages.scm
 gnu/services.scm
 gnu/system.scm

Re: Reporting module errors

[myglc2]

On 11/07/2017 at 23:47 Ludovic Courtès writes:

> Hello!
>
> You’re too fast!  :-)
>
> julien lepiller <julien@lepiller.eu> skribis:
>
[...]
>
> I’d propose a variant of it, see below.  With this, one gets a message
> like:
>
>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found
>
> where line 6 is:
>
>   (use-package-modules foobar)
>
> How does that sound?
>
> It lacks the hints that you were proposing, which isn’t great, but I
> think we’d need to provide a homogeneous and internationalized API in
> (guix ui) if we are to display hints.  But overall I like the idea of
> providing hints somehow.
>
> Perhaps we could simply introduce another condition type for hints as a
> first step, similar to ‘&message’?
>
> Speaking of hints, we should have something that suggests a module name
> based on the Levenshtein distance with available modules.  :-)
>
> Thanks,
> Ludo’.

FWIW, if you give me the choice between no hints and the hints produced
by julien's patch translated into a random foreign (to me) language, I
strongly prefer the hints.

Why? Because I am will benefit from the embedded data/examples (e.g.,
`guix package --show=foo | grep location`, which, by the way, will never
be translated) even when I do not understand the surrounding words.

Wouldn't speakers of any language feel this way about these specific
hints?

WDYT?

- George

Re: Reporting module errors

[Hartmut Goebel]

Am 07.11.2017 um 23:47 schrieb Ludovic Courtès:
>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found

Since one of the aims of guix is to empower users, this is more cryptic.
One needs to know that ":6:0" means "line 6". Thus such a terse message
raises the bar.

I agree with George: Even if I so not understand the language the hint
is written in (English!), the hint is still, l useful since it contains
commands i can try. If you ever picked log-entries and commands from a
Russian, Chinese, Japaneses, etc web-site, you know what I mean.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Reporting module errors

[Ludovic Courtès]

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 07.11.2017 um 23:47 schrieb Ludovic Courtès:
>>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found
>
> Since one of the aims of guix is to empower users, this is more cryptic.
> One needs to know that ":6:0" means "line 6". Thus such a terse message
> raises the bar.

Well, Guix has always reported source code location like this, and
besides Guix all GNU tools and many non-GNU tools do.  At some point we
have to agree on conventions…

Ludo’.

[PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Hi!

Here’s an improved version that supports hints (with Texinfo markup and
i18n) and error reporting with source location info.

Hints try to make suggestions.  If you write:

  (use-package-modules qemu)

You’ll get:

  configuration.scm:7:0: error: module (gnu packages qemu) not found
  hint: Did you mean `(use-package-modules virtualization)'?

If you write:

  (use-service-modules openssh)

You get:

  configuration.scm:9:0: error: module (gnu services openssh) not found
  hint: Did you mean `(use-service-modules ssh)'?

The “did you mean” hints are based on exact matches on the package or
service names.  We could go as far as doing inexact searches akin to
what “guix package -s” and “guix system search” do, but maybe that’s
overkill given that the suggestions could be wrong.

Anyway, I think that’s already an improvement and we can always refine
it later.

Thoughts?

Ludo’.

Ludovic Courtès (6):
  ui: Introduce (guix i18n).
  ui: Define and honor '&error-location' and '&fix-hint' conditions.
  services: 'fold-service-types' honors its seed.
  services: 'fold-service-types' includes (gnu services).
  services: Add 'lookup-service-types'.
  gnu: Improve error reporting of the use-.*modules macros.

 Makefile.am          |   1 +
 gnu.scm              | 100 ++++++++++++++++++++++++++++++++++++++++++++++++---
 gnu/services.scm     |  20 +++++++++--
 guix/i18n.scm        |  51 ++++++++++++++++++++++++++
 guix/ui.scm          |  50 ++++++++++++--------------
 guix/utils.scm       |  17 +++++++++
 po/guix/POTFILES.in  |   1 +
 tests/guix-system.sh |  28 +++++++++++++++
 tests/services.scm   |  10 +++++-
 9 files changed, 243 insertions(+), 35 deletions(-)
 create mode 100644 guix/i18n.scm

-- 
2.15.0

[PATCH 1/6] ui: Introduce (guix i18n).

[Ludovic Courtès]

* guix/ui.scm (G_, N_, _P, %gettext-domain, %package-text-domain): Move
to...
* guix/i18n.scm: ... here.  New file.
---
 Makefile.am   |  1 +
 guix/i18n.scm | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 guix/ui.scm   | 27 +++------------------------
 3 files changed, 55 insertions(+), 24 deletions(-)
 create mode 100644 guix/i18n.scm

diff --git a/Makefile.am b/Makefile.am
index 41fb9ba38..7ad95cec7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -103,6 +103,7 @@ MODULES =					\
   guix/store.scm				\
   guix/cvs-download.scm				\
   guix/svn-download.scm				\
+  guix/i18n.scm					\
   guix/ui.scm					\
   guix/build/ant-build-system.scm		\
   guix/build/download.scm			\
diff --git a/guix/i18n.scm b/guix/i18n.scm
new file mode 100644
index 000000000..f81e6b38e
--- /dev/null
+++ b/guix/i18n.scm
@@ -0,0 +1,51 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (guix i18n)
+  #:use-module (srfi srfi-26)
+  #:export (G_
+            N_
+            P_
+            %gettext-domain
+            %package-text-domain))
+
+;;; Commentary:
+;;;
+;;; Internationalization support.
+;;;
+;;; Code:
+
+(define %gettext-domain
+  ;; Text domain for strings used in the tools.
+  "guix")
+
+(define %package-text-domain
+  ;; Text domain for package synopses and descriptions.
+  "guix-packages")
+
+(define G_ (cut gettext <> %gettext-domain))
+(define N_ (cut ngettext <> <> <> %gettext-domain))
+
+(define (P_ msgid)
+  "Return the translation of the package description or synopsis MSGID."
+  ;; Descriptions/synopses might occasionally be empty strings, even if that
+  ;; is something we try to avoid.  Since (gettext "") can return a non-empty
+  ;; string, explicitly check for that case.
+  (if (string-null? msgid)
+      msgid
+      (gettext msgid %package-text-domain)))
diff --git a/guix/ui.scm b/guix/ui.scm
index 3c8734a7d..40371e471 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -26,6 +26,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (guix ui)
+  #:use-module (guix i18n)
   #:use-module (guix gexp)
   #:use-module (guix utils)
   #:use-module (guix store)
@@ -55,10 +56,8 @@
   #:use-module (texinfo)
   #:use-module (texinfo plain-text)
   #:use-module (texinfo string-utils)
-  #:export (G_
-            N_
-            P_
-            report-error
+  #:re-export (G_ N_ P_)                          ;backward compatibility
+  #:export (report-error
             leave
             make-user-module
             load*
@@ -111,26 +110,6 @@
 ;;;
 ;;; Code:
 
-(define %gettext-domain
-  ;; Text domain for strings used in the tools.
-  "guix")
-
-(define %package-text-domain
-  ;; Text domain for package synopses and descriptions.
-  "guix-packages")
-
-(define G_ (cut gettext <> %gettext-domain))
-(define N_ (cut ngettext <> <> <> %gettext-domain))
-
-(define (P_ msgid)
-  "Return the translation of the package description or synopsis MSGID."
-  ;; Descriptions/synopses might occasionally be empty strings, even if that
-  ;; is something we try to avoid.  Since (gettext "") can return a non-empty
-  ;; string, explicitly check for that case.
-  (if (string-null? msgid)
-      msgid
-      (gettext msgid %package-text-domain)))
-
 (define-syntax-rule (define-diagnostic name prefix)
   "Create a diagnostic macro (i.e., NAME), which will prepend PREFIX to all
 messages."
-- 
2.15.0

[PATCH 2/6] ui: Define and honor '&error-location' and '&fix-hint' conditions.

[Ludovic Courtès]

* guix/utils.scm (&error-location, &fix-hint): New condition types.
* guix/ui.scm (report-load-error): Handle them.
(call-with-error-handling): Honor '&error-location'.
---
 guix/ui.scm    | 23 +++++++++++++++++++----
 guix/utils.scm | 17 +++++++++++++++++
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/guix/ui.scm b/guix/ui.scm
index 40371e471..a1152605e 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -251,10 +251,20 @@ ARGS is the list of arguments received by the 'throw' handler."
                (location->string loc) message)))
     (('srfi-34 obj)
      (if (message-condition? obj)
-         (report-error (G_ "~a~%")
-                       (gettext (condition-message obj)
-                                %gettext-domain))
-         (report-error (G_ "exception thrown: ~s~%") obj)))
+         (if (error-location? obj)
+             (format (current-error-port)
+                     (G_ "~a: error: ~a~%")
+                     (location->string (error-location obj))
+                     (gettext (condition-message obj)
+                              %gettext-domain))
+             (report-error (G_ "~a~%")
+                           (gettext (condition-message obj)
+                                    %gettext-domain)))
+         (report-error (G_ "exception thrown: ~s~%") obj))
+     (when (fix-hint? obj)
+       (format (current-error-port) (G_ "hint: ~a~%")
+               (fill-paragraph (texi->plain-text (condition-fix-hint obj))
+                               (terminal-columns) 8))))
     ((error args ...)
      (report-error (G_ "failed to load '~a':~%") file)
      (apply display-error frame (current-error-port) args))))
@@ -517,6 +527,11 @@ interpreted."
 directories:~{ ~a~}~%")
                     (file-search-error-file-name c)
                     (file-search-error-search-path c)))
+            ((and (error-location? c) (message-condition? c))
+             (format (current-error-port)
+                     (G_ "~a: error: ~a~%")
+                     (location->string (error-location c))
+                     (gettext (condition-message c) %gettext-domain)))
             ((message-condition? c)
              ;; Normally '&message' error conditions have an i18n'd message.
              (leave (G_ "~a~%")
diff --git a/guix/utils.scm b/guix/utils.scm
index eb1ec29b3..c0ffed172 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -28,6 +28,7 @@
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
+  #:use-module (srfi srfi-35)
   #:use-module (srfi srfi-39)
   #:use-module (ice-9 binary-ports)
   #:autoload   (rnrs io ports) (make-custom-binary-input-port)
@@ -60,6 +61,14 @@
             source-properties->location
             location->source-properties
 
+            &error-location
+            error-location?
+            error-location
+
+            &fix-hint
+            fix-hint?
+            condition-fix-hint
+
             nix-system->gnu-triplet
             gnu-triplet->nix-system
             %current-system
@@ -750,6 +759,14 @@ a location object."
     (column   . ,(location-column loc))
     (filename . ,(location-file loc))))
 
+(define-condition-type &error-location &error
+  error-location?
+  (location  error-location))                     ;<location>
+
+(define-condition-type &fix-hint &condition
+  fix-hint?
+  (hint condition-fix-hint))                      ;string
+
 ;;; Local Variables:
 ;;; eval: (put 'call-with-progress-reporter 'scheme-indent-function 1)
 ;;; End:
-- 
2.15.0

[PATCH 3/6] services: 'fold-service-types' honors its seed.

[Ludovic Courtès]

* gnu/services.scm (fold-service-types): Use SEED instead of '().
---
 gnu/services.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index 50be28a38..89c5d52c8 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -184,7 +184,7 @@ is used as the initial value of RESULT."
                                   (if (service-type? object)
                                       (proc object result)
                                       result))
-                                '()
+                                seed
                                 modules))
 
 ;; Services of a given type.
-- 
2.15.0

[PATCH 4/6] services: 'fold-service-types' includes (gnu services).

[Ludovic Courtès]

* gnu/services.scm (all-service-modules): New procedure.
(fold-service-types): Use it for the default MODULES value.
---
 gnu/services.scm | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index 89c5d52c8..df1bedeb9 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -175,9 +175,14 @@
   (make-parameter `((,%distro-root-directory . "gnu/services")
                     (,%distro-root-directory . "gnu/system"))))
 
+(define (all-service-modules)
+  "Return the default set of service modules."
+  (cons (resolve-interface '(gnu services))
+        (all-modules (%service-type-path))))
+
 (define* (fold-service-types proc seed
                              #:optional
-                             (modules (all-modules (%service-type-path))))
+                             (modules (all-service-modules)))
   "For each service type exported by one of MODULES, call (PROC RESULT).  SEED
 is used as the initial value of RESULT."
   (fold-module-public-variables (lambda (object result)
-- 
2.15.0

[PATCH 5/6] services: Add 'lookup-service-types'.

[Ludovic Courtès]

* gnu/services.scm (lookup-service-types): New procedure.
* tests/services.scm ("lookup-service-types"): New test.
---
 gnu/services.scm   | 11 +++++++++++
 tests/services.scm | 10 +++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index df1bedeb9..016ff08e0 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -55,6 +55,7 @@
 
             %service-type-path
             fold-service-types
+            lookup-service-types
 
             service
             service?
@@ -192,6 +193,16 @@ is used as the initial value of RESULT."
                                 seed
                                 modules))
 
+(define lookup-service-types
+  (let ((table
+         (delay (fold-service-types (lambda (type result)
+                                      (vhash-consq (service-type-name type)
+                                                   type result))
+                                    vlist-null))))
+    (lambda (name)
+      "Return the list of services with the given NAME (a symbol)."
+      (vhash-foldq* cons '() name (force table)))))
+
 ;; Services of a given type.
 (define-record-type <service>
   (make-service type value)
diff --git a/tests/services.scm b/tests/services.scm
index 8484ee982..ca32b565c 100644
--- a/tests/services.scm
+++ b/tests/services.scm
@@ -23,7 +23,8 @@
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-34)
-  #:use-module (srfi srfi-64))
+  #:use-module (srfi srfi-64)
+  #:use-module (ice-9 match))
 
 (define live-service
   (@@ (gnu services herd) live-service))
@@ -206,4 +207,11 @@
       (list (map live-service-provision unload)
             (map shepherd-service-provision load)))))
 
+(test-eq "lookup-service-types"
+  system-service-type
+  (and (null? (lookup-service-types 'does-not-exist-at-all))
+       (match (lookup-service-types 'system)
+         ((one) one)
+         (x x))))
+
 (test-end)
-- 
2.15.0

[PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Ludovic Courtès]

Suggested by Julien Lepiller and myglc2
at <https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00106.html>.

* gnu.scm (%try-use-modules): New procedure.
(package-module-hint, service-module-hint): New procedures.
(try-use-modules): New macro.
(use-package-modules, use-service-modules, use-system-modules): Use it.
* tests/guix-system.sh: Test it.
---
 gnu.scm              | 100 ++++++++++++++++++++++++++++++++++++++++++++++++---
 po/guix/POTFILES.in  |   1 +
 tests/guix-system.sh |  28 +++++++++++++++
 3 files changed, 125 insertions(+), 4 deletions(-)

diff --git a/gnu.scm b/gnu.scm
index 913ce6160..35cd2a7f6 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015, 2016 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2015 Joshua S. Grant <jgrant@parenthetical.io>
 ;;; Copyright © 2017 Mathieu Othacehe <m.othacehe@gmail.com>
 ;;;
@@ -19,6 +19,14 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu)
+  #:use-module (guix i18n)
+  #:use-module (guix utils)
+  #:use-module (srfi srfi-34)
+  #:use-module (srfi srfi-35)
+  #:use-module (ice-9 match)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu services)
   #:export (use-package-modules
             use-service-modules
             use-system-modules))
@@ -52,13 +60,97 @@
                   (module-use! i (resolve-interface m))))
               %public-modules)))
 
+(define (%try-use-modules modules location make-hint)
+  "Attempt to load all of MODULES.  Report errors as coming from LOCATION, a
+<location> record, and use MAKE-HINT to produce a fix hint."
+  (define (location->string loc)
+    (match loc
+      (#f "")
+      (($ <location> file line column)
+       (format #f "~a:~a:~a: " file line column))))
+
+  (for-each (lambda (module)
+              (catch 'misc-error
+                (lambda ()
+                  (process-use-modules `((,module))))
+                (lambda _
+                  (raise
+                   (apply
+                    make-compound-condition
+                    (condition
+                     (&message
+                      (message (format #f (G_ "module ~a not found")
+                                       module))))
+                    (condition
+                     (&error-location (location location)))
+                    (or (and=> (make-hint module) list)
+                        '()))))))
+            modules))
+
+(define (package-module-hint module)
+  (define last-name
+    (match module
+      ((_ ... last)
+       (symbol->string last))))
+
+  (match (find-packages-by-name last-name)
+    (()
+     (condition
+      (&fix-hint
+       (hint (G_ "\
+You may use @command{guix package --show=foo | grep location} to search
+for the location of package @code{foo}.
+If you get the line @code{location: gnu/packages/bar.scm:174:2},
+add @code{bar} to the @code{use-package-modules} form.")))))
+    ((package _ ...)
+     (condition
+      (&fix-hint
+       (hint (format #f (G_ "\
+Did you mean @code{(use-package-modules ~a)}?")
+                     (basename (location-file (package-location package))
+                               ".scm"))))))))
+
+(define (service-module-hint module)
+  (define last-name
+    (match module
+      ((_ ... last)
+       last)))
+
+  (match (lookup-service-types last-name)
+    (()
+     (condition
+      (&fix-hint
+       (hint (format #f (G_ "\
+You may use @command{guix system search ~a} to search for a service
+matching @code{~a}.
+If you get the line @code{location: gnu/services/foo.scm:188:2},
+add @code{foo} to the @code{use-service-modules} form.")
+                     last-name last-name)))))
+    ((package _ ...)
+     (condition
+      (&fix-hint
+       (hint (format #f (G_ "\
+Did you mean @code{(use-service-modules ~a)}?")
+                     (basename (location-file (service-type-location package))
+                               ".scm"))))))))
+
+(define-syntax-rule (try-use-modules hint modules ...)
+  (eval-when (expand load eval)
+    (%try-use-modules '(modules ...)
+                      (source-properties->location
+                       (current-source-location))
+                      hint)))
+
 (define-syntax-rule (use-package-modules module ...)
-  (use-modules (gnu packages module) ...))
+  (try-use-modules package-module-hint
+                   (gnu packages module) ...))
 
 (define-syntax-rule (use-service-modules module ...)
-  (use-modules (gnu services module) ...))
+  (try-use-modules service-module-hint
+                   (gnu services module) ...))
 
 (define-syntax-rule (use-system-modules module ...)
-  (use-modules (gnu system module) ...))
+  (try-use-modules (const #f)                     ;no hint
+                   (gnu system module) ...))
 
 ;;; gnu.scm ends here
diff --git a/po/guix/POTFILES.in b/po/guix/POTFILES.in
index e3f767cc6..6510b99e8 100644
--- a/po/guix/POTFILES.in
+++ b/po/guix/POTFILES.in
@@ -1,5 +1,6 @@
 # List of source files which contain translatable strings.
 # This should be source files of the various tools, and not package modules.
+gnu.scm
 gnu/packages.scm
 gnu/services.scm
 gnu/system.scm
diff --git a/tests/guix-system.sh b/tests/guix-system.sh
index 31ee63713..0cd0aa944 100644
--- a/tests/guix-system.sh
+++ b/tests/guix-system.sh
@@ -68,6 +68,34 @@ else
 fi
 
 
+# Reporting of module not found errors.
+
+cat > "$tmpfile" <<EOF
+;; Line 1.
+(use-modules (gnu))
+  (use-service-modules openssh)
+EOF
+
+if guix system build "$tmpfile" -n 2> "$errorfile"
+then false
+else
+    grep "$tmpfile:3:2: .*module .*openssh.*not found" "$errorfile"
+    grep "Did you mean.*use-service-modules ssh" "$errorfile"
+fi
+
+cat > "$tmpfile" <<EOF
+;; Line 1.
+(use-modules (gnu))
+  (use-package-modules qemu)
+EOF
+
+if guix system build "$tmpfile" -n 2> "$errorfile"
+then false
+else
+    grep "$tmpfile:3:2: .*module .*qemu.*not found" "$errorfile"
+    grep "Did you mean.*use-package-modules virtualization" "$errorfile"
+fi
+
 # Reporting of unbound variables.
 
 cat > "$tmpfile" <<EOF
-- 
2.15.0

Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Chris Marusich]

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

Hi Ludo,

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

> +(define-syntax-rule (try-use-modules hint modules ...)
> +  (eval-when (expand load eval)
> +    (%try-use-modules '(modules ...)
> +                      (source-properties->location
> +                       (current-source-location))
> +                      hint)))
> +

Why is it necessary to use eval-when here?  The Guile manual makes it
sound like eval-when is intended to be used with syntax-case macros, not
syntax-rules macros.

-- 
Chris

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

Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Ludovic Courtès]

Heya,

Chris Marusich <cmmarusich@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> +(define-syntax-rule (try-use-modules hint modules ...)
>> +  (eval-when (expand load eval)
>> +    (%try-use-modules '(modules ...)
>> +                      (source-properties->location
>> +                       (current-source-location))
>> +                      hint)))
>> +
>
> Why is it necessary to use eval-when here?  The Guile manual makes it
> sound like eval-when is intended to be used with syntax-case macros, not
> syntax-rules macros.

It’s necessary because ‘use-modules’ (and ‘try-use-modules’ here)
doesn’t allow you to specify the “phase” (run-time or expansion-time) at
which you’re “using” the module.  Thus, it assumes you’re using it both
at expansion-time and at run-time.

The (gnu packages …) modules happen to export a few macros, so it
doesn’t work if you import them at run-time only.

Ludo’.

Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Chris Marusich]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Heya,
>
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> +(define-syntax-rule (try-use-modules hint modules ...)
>>> +  (eval-when (expand load eval)
>>> +    (%try-use-modules '(modules ...)
>>> +                      (source-properties->location
>>> +                       (current-source-location))
>>> +                      hint)))
>>> +
>>
>> Why is it necessary to use eval-when here?  The Guile manual makes it
>> sound like eval-when is intended to be used with syntax-case macros, not
>> syntax-rules macros.
>
> It’s necessary because ‘use-modules’ (and ‘try-use-modules’ here)
> doesn’t allow you to specify the “phase” (run-time or expansion-time) at
> which you’re “using” the module.  Thus, it assumes you’re using it both
> at expansion-time and at run-time.
>
> The (gnu packages …) modules happen to export a few macros, so it
> doesn’t work if you import them at run-time only.

I see.  Thank you for the explanation.  I think I need to read up more
on how Guile loads, evaluates, compiles, etc. its code.

-- 
Chris

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

Re: [PATCH 0/6] Error reporting and hints for missing modules

[julien lepiller]

Le 2017-11-08 14:09, Ludovic Courtès a écrit :
> Hi!
> 
> Here’s an improved version that supports hints (with Texinfo markup and
> i18n) and error reporting with source location info.
> 
> Hints try to make suggestions.  If you write:
> 
>   (use-package-modules qemu)
> 
> You’ll get:
> 
>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>   hint: Did you mean `(use-package-modules virtualization)'?
> 
> If you write:
> 
>   (use-service-modules openssh)
> 
> You get:
> 
>   configuration.scm:9:0: error: module (gnu services openssh) not found
>   hint: Did you mean `(use-service-modules ssh)'?
> 
> The “did you mean” hints are based on exact matches on the package or
> service names.  We could go as far as doing inexact searches akin to
> what “guix package -s” and “guix system search” do, but maybe that’s
> overkill given that the suggestions could be wrong.
> 
> Anyway, I think that’s already an improvement and we can always refine
> it later.
> 
> Thoughts?

This is great! I don't understand it all, but it seems like when there 
is
no exact match for a package or service, we get the more generic hint
I wrote.

I'm happy with this version, so LGTM (though untested). Let's see what
George thinks about it.


> 
> Ludo’.
> 
> Ludovic Courtès (6):
>   ui: Introduce (guix i18n).
>   ui: Define and honor '&error-location' and '&fix-hint' conditions.
>   services: 'fold-service-types' honors its seed.
>   services: 'fold-service-types' includes (gnu services).
>   services: Add 'lookup-service-types'.
>   gnu: Improve error reporting of the use-.*modules macros.
> 
>  Makefile.am          |   1 +
>  gnu.scm              | 100 
> ++++++++++++++++++++++++++++++++++++++++++++++++---
>  gnu/services.scm     |  20 +++++++++--
>  guix/i18n.scm        |  51 ++++++++++++++++++++++++++
>  guix/ui.scm          |  50 ++++++++++++--------------
>  guix/utils.scm       |  17 +++++++++
>  po/guix/POTFILES.in  |   1 +
>  tests/guix-system.sh |  28 +++++++++++++++
>  tests/services.scm   |  10 +++++-
>  9 files changed, 243 insertions(+), 35 deletions(-)
>  create mode 100644 guix/i18n.scm

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/08/2017 at 16:33 julien lepiller writes:

> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>> Hi!
>>
>> Here’s an improved version that supports hints (with Texinfo markup and
>> i18n) and error reporting with source location info.
>>
>> Hints try to make suggestions.  If you write:
>>
>>   (use-package-modules qemu)
>>
>> You’ll get:
>>
>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>   hint: Did you mean `(use-package-modules virtualization)'?
>>
>> If you write:
>>
>>   (use-service-modules openssh)
>>
>> You get:
>>
>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>   hint: Did you mean `(use-service-modules ssh)'?
>>
>> The “did you mean” hints are based on exact matches on the package or
>> service names.  We could go as far as doing inexact searches akin to
>> what “guix package -s” and “guix system search” do, but maybe that’s
>> overkill given that the suggestions could be wrong.
>>
>> Anyway, I think that’s already an improvement and we can always refine
>> it later.
>>
>> Thoughts?
>
> This is great! I don't understand it all, but it seems like when there
> is
> no exact match for a package or service, we get the more generic hint
> I wrote.
>
> I'm happy with this version, so LGTM (though untested). Let's see what
> George thinks about it.

Oh YEAH! This is truly awesome!

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

Hi Ludo’,

I built and played with this. I see you also provide a search hint when
you don't find an obvious match, as in ...

sys.scm:3:0: error: module (gnu services sshx) not found
hint: You may use `guix system search sshx' to search for a service matching `sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add `foo' to the `use-service-modules'
form.

This is very nice indeed.

Based on testing, may I suggest the hint rewording shown below ...

On 11/08/2017 at 12:42 myglc2 writes:

> On 11/08/2017 at 16:33 julien lepiller writes:
>
>> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>>> Hi!
>>>
>>> Here’s an improved version that supports hints (with Texinfo markup and
>>> i18n) and error reporting with source location info.
>>>
>>> Hints try to make suggestions.  If you write:
>>>
>>>   (use-package-modules qemu)
>>>
>>> You’ll get:
>>>
>>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>>   hint: Did you mean `(use-package-modules virtualization)'?

hint: Try adding `(use-package-modules virtualization)'

>>>
>>> If you write:
>>>
>>>   (use-service-modules openssh)
>>>
>>> You get:
>>>
>>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>>   hint: Did you mean `(use-service-modules ssh)'?

hint: Try adding `(use-service-modules ssh)'

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Hi,

myglc2 <myglc2@gmail.com> skribis:

> I built and played with this. I see you also provide a search hint when
> you don't find an obvious match, as in ...
>
> sys.scm:3:0: error: module (gnu services sshx) not found
> hint: You may use `guix system search sshx' to search for a service matching `sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add `foo' to the `use-service-modules'
> form.
>
> This is very nice indeed.

Glad you like it.

>>>> You get:
>>>>
>>>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>>>   hint: Did you mean `(use-service-modules ssh)'?
>
> hint: Try adding `(use-service-modules ssh)'

Good idea.  I’ve made this change and pushed.

Thanks to the two of you!  I think this is really the kind of UI/UX
improvements we should be making, but die-hard Guix hackers like me
don’t necessarily think about it, so it’s great that you came up with
this idea.

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Hello,

myglc2 <myglc2@gmail.com> skribis:

> I built and played with this. I see you also provide a search hint when
> you don't find an obvious match, as in ...
>
> sys.scm:3:0: error: module (gnu services sshx) not found
> hint: You may use `guix system search sshx' to search for a service matching `sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add `foo' to the `use-service-modules'
> form.

Thrilled by this idea, I pushed an unbound-variable handler that can
provide hints, such as:

  configuration.scm:88:19: zip: unbound variable
  hint: Try adding `(use-modules (gnu packages compression))'.

Feedback welcome!

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a2985bb101faac9f085176e0329488b91b81dfb5

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

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

On 11/10/2017 at 00:04 Ludovic Courtès writes:
>
> Thrilled by this idea, I pushed an unbound-variable handler that can
> provide hints, such as:
>
>   configuration.scm:88:19: zip: unbound variable
>   hint: Try adding `(use-modules (gnu packages compression))'.
>
> Feedback welcome!

I built and played with this.  If I follow some of the hints literally
they lead me astray. Here are some suggested hint rewording.

Note: You can reproduce the errors/hints below with the attached files.

HTH - George

HINT REWORDING SUGGESTIONS:

 *** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED"

The error messages ...

/root/ctest/test2:4:0: error: module (gnu packages qemu) not found
hint: Try adding `(use-package-modules virtualization)'.

... are followed literally in test2.fix, which does not fix the
problem because the stale and non-existant 'qemu' package module
reference also needs to be removed.

Maybe a better hint would be ...

hint: Remove the reference to the pachage module that was not 
hint: found and add `(use-package-modules virtualization)'.

 *** test3: 'NON EXISTANT (openssh) SERVICE MODULE specified'

This has the same conceptual problem as test2 above. 

The error messages ...

/root/ctest/test3:3:0: error: module (gnu services openssh) not found
hint: Try adding `(use-service-modules ssh)'.

... are followed literally in test3.fix, which does not fix the
problem because the non-existant 'openssh' service module
reference also needs to be removed.

Maybe a better hint would be ...

hint: Remove the reference to the service module that was not 
hint: found and add `(use-service-modules ssh)'.

 *** test4: "SERVICE MODULE (ssh) for openssh-service-type SERVICE MISSING"

A more helpful hint here ...

/root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type: unbound variable
hint: Did you forget a `use-modules' form?

... would be ...

hint: Try adding `(use-service-modules ssh)'.

 ***
 
VERSION INFO:

74bea6a03 gnu: linux-libre: Update to 4.13.12.

make check failed as reported in bug#29245 but I don't think those
errors affect what I am seeing here.

TEST FILES:


[-- Attachment #2: test0.scm --]
[-- Type: application/octet-stream, Size: 1657 bytes --]

;;; GuixSD headless server
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules
 virtualization
 )
(operating-system
  (host-name "g1")
  (timezone "America/New_York")
  (locale "en_US.utf8")
  (kernel-arguments '("console=ttyS1,115200"))
  ;; RAID1 root using 1 NVMe SSD + 2 HDs
  (bootloader (grub-configuration (target "/dev/nvme0n1")
				  (terminal-outputs '(console))
				  (terminal-inputs '(serial console))
				  (serial-speed 115200)				  
				  ))
  (initrd (lambda (file-systems . rest) (apply base-initrd file-systems
					       #:extra-modules '("raid1")
					       rest)))
  (mapped-devices (list (mapped-device
			 (source '("/dev/nvme0n1p1" "/dev/sda1" "/dev/sdb1"))
			 (target "/dev/md3")
			 (type raid-device-mapping))))
  (file-systems (cons (file-system
			(title 'device)
			(device "/dev/md3")
			(mount-point "/")
			(type "ext4")
			(dependencies mapped-devices))
		      %base-file-systems))
  (swap-devices '("/dev/nvme0n1p2" ))
  (users (cons* (user-account (name "g1")
			      (group "users")
			      (supplementary-groups '("wheel" "kvm"))
			      (home-directory (string-append "/home/" name)))
		(user-account (name "admin")
			      (group "users")
			      (supplementary-groups '("wheel" "kvm"))
			      (home-directory (string-append "/home/" name)))
		%base-user-accounts))
  (packages (cons*
	     qemu
	     %base-packages))
  (services (cons* (dhcp-client-service)
		   (ntp-service)
		   (service openssh-service-type (openssh-configuration
						  (x11-forwarding? #t)))
		   (agetty-service (agetty-configuration (tty "ttyS1")
							 (baud-rate "115200")))
		   %base-services)))

[-- Attachment #3: try.sh --]
[-- Type: application/x-sh, Size: 1517 bytes --]

[-- Attachment #4: try.sh.log --]
[-- Type: application/octet-stream, Size: 3157 bytes --]

+ echo test0: 'CONFIRM BASE CASE WORKS'
test0: CONFIRM BASE CASE WORKS
+ guix system build test0.scm
/gnu/store/cbxq30y970hhcn8dyyi9imzs716lvnkj-system
+ echo

+ echo test1: 'PACKAGE MODULE for qemu PACKAGE (virtualization) IS NOT SPECIFIED'
test1: PACKAGE MODULE for qemu PACKAGE (virtualization) IS NOT SPECIFIED
+ sed /virtualization/d test0.scm
+ diff test0.scm test1
5d4
<  virtualization
+ guix system build test1
/root/ctest/test1:32:9: /root/ctest/test1:32:9: qemu: unbound variable
hint: Try adding `(use-modules (gnu packages virtualization))'.
+ echo

+ echo test1.fix:
test1.fix:
+ sed '/virtualization/d 
/(use-package-modules/i(use-modules (gnu packages virtualization))' test0.scm
+ diff test0.scm test1.fix
3a4
> (use-modules (gnu packages virtualization))
5d5
<  virtualization
+ guix system build test1.fix
/gnu/store/cbxq30y970hhcn8dyyi9imzs716lvnkj-system
+ echo

+ echo test2: 'NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED'
test2: NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED
+ sed s/virtualization/qemu/ test0.scm
+ diff test0.scm test2
5c5
<  virtualization
---
>  qemu
+ guix system build test2
/root/ctest/test2:4:0: error: module (gnu packages qemu) not found
hint: Try adding `(use-package-modules virtualization)'.
+ echo

+ echo test2.fix
test2.fix
+ sed 's/virtualization/qemu/
/(use-package-modules/ i(use-package-modules virtualization)
' test0.scm
+ diff test0.scm test2.fix
3a4
> (use-package-modules virtualization)
5c6
<  virtualization
---
>  qemu
+ guix system build test2.fix
/root/ctest/test2.fix:5:0: error: module (gnu packages qemu) not found
hint: Try adding `(use-package-modules virtualization)'.
+ echo

+ echo test3: 'NON EXISTANT (openssh) SERVICE MODULE specified'
test3: NON EXISTANT (openssh) SERVICE MODULE specified
+ sed 's/(use-service-modules networking ssh)/(use-service-modules networking openssh)/' test0.scm
+ diff test0.scm test3
3c3
< (use-service-modules networking ssh)
---
> (use-service-modules networking openssh)
+ guix system build test3
/root/ctest/test3:3:0: error: module (gnu services openssh) not found
hint: Try adding `(use-service-modules ssh)'.
+ echo

+ echo test3.fix
test3.fix
+ sed 's/(use-service-modules networking ssh)/(use-service-modules networking openssh)/
/(use-service-modules/ i(use-service-modules ssh)
' test0.scm
+ diff test0.scm test3.fix
3c3,4
< (use-service-modules networking ssh)
---
> (use-service-modules ssh)
> (use-service-modules networking openssh)
+ guix system build test3.fix
/root/ctest/test3.fix:4:0: error: module (gnu services openssh) not found
hint: Try adding `(use-service-modules ssh)'.
+ echo

+ echo test4: 'SERVICE MODULE (ssh) for openssh-service-type SERVICE MISSING'
test4: SERVICE MODULE (ssh) for openssh-service-type SERVICE MISSING
+ sed 's/(use-service-modules networking ssh)/(use-service-modules networking)/' test0.scm
+ diff test0.scm test4
3c3
< (use-service-modules networking ssh)
---
> (use-service-modules networking)
+ guix system build test4
/root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type: unbound variable
hint: Did you forget a `use-modules' form?
+ echo

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Julien Lepiller]

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

Le 10 novembre 2017 15:47:37 GMT+01:00, myglc2 <myglc2@gmail.com> a écrit :
>On 11/10/2017 at 00:04 Ludovic Courtès writes:
>>
>> Thrilled by this idea, I pushed an unbound-variable handler that can
>> provide hints, such as:
>>
>>   configuration.scm:88:19: zip: unbound variable
>>   hint: Try adding `(use-modules (gnu packages compression))'.
>>
>> Feedback welcome!
>
>I built and played with this.  If I follow some of the hints literally
>they lead me astray. Here are some suggested hint rewording.
>
>Note: You can reproduce the errors/hints below with the attached files.
>
>HTH - George
>
>HINT REWORDING SUGGESTIONS:
>
>*** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE
>SPECIFIED"
>
>The error messages ...
>
>/root/ctest/test2:4:0: error: module (gnu packages qemu) not found
>hint: Try adding `(use-package-modules virtualization)'.
>
>... are followed literally in test2.fix, which does not fix the
>problem because the stale and non-existant 'qemu' package module
>reference also needs to be removed.
>
>Maybe a better hint would be ...
>
>hint: Remove the reference to the pachage module that was not 
>hint: found and add `(use-package-modules virtualization)'.
>
> *** test3: 'NON EXISTANT (openssh) SERVICE MODULE specified'
>
>This has the same conceptual problem as test2 above. 
>
>The error messages ...
>
>/root/ctest/test3:3:0: error: module (gnu services openssh) not found
>hint: Try adding `(use-service-modules ssh)'.
>
>... are followed literally in test3.fix, which does not fix the
>problem because the non-existant 'openssh' service module
>reference also needs to be removed.
>
>Maybe a better hint would be ...
>
>hint: Remove the reference to the service module that was not 
>hint: found and add `(use-service-modules ssh)'.
>
>*** test4: "SERVICE MODULE (ssh) for openssh-service-type SERVICE
>MISSING"
>
>A more helpful hint here ...
>
>/root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type:
>unbound variable
>hint: Did you forget a `use-modules' form?
>
>... would be ...
>
>hint: Try adding `(use-service-modules ssh)'.
>
> ***
> 
>VERSION INFO:
>
>74bea6a03 gnu: linux-libre: Update to 4.13.12.
>
>make check failed as reported in bug#29245 but I don't think those
>errors affect what I am seeing here.
>
>TEST FILES:

I saw that last hint today buveuse I misspelled a type name (dovecot-configurtation). I understand the hint is great when you forget to import a service module, but it's not so great when the error is misspelling. Maybe the solution would be: if the unbound variable is the name of a service, propose using that module, otherwise don't show any hint. 

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

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Julien Lepiller <julien@lepiller.eu> skribis:

> I saw that last hint today buveuse I misspelled a type name (dovecot-configurtation). I understand the hint is great when you forget to import a service module, but it's not so great when the error is misspelling. Maybe the solution would be: if the unbound variable is the name of a service, propose using that module, otherwise don't show any hint. 

A hint is nothing more than that, a hint (as opposed to a “solution”),
but maybe you’re right about removing the “Did you forget ‘use-modules’”
hint.

Thoughts?

(Misspelling is where we’d need something using the Levensthein
distance.  I’m sure one could do a PhD on this topic.  :-))

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> On 11/10/2017 at 00:04 Ludovic Courtès writes:
>>
>> Thrilled by this idea, I pushed an unbound-variable handler that can
>> provide hints, such as:
>>
>>   configuration.scm:88:19: zip: unbound variable
>>   hint: Try adding `(use-modules (gnu packages compression))'.
>>
>> Feedback welcome!
>
> I built and played with this.  If I follow some of the hints literally
> they lead me astray. Here are some suggested hint rewording.

Again, it’s a hint, it could be wrong.

So perhaps that’s a good reason for “Did you mean xyz?”, ending with a
question mark (like GCC does), rather than a sentence that looks
assertive.

In the example above, it may be less confusing if we write:

  Did you forget (use-modules …)?

With the question mark, the user understands that this may or may not be
the cause of the error.

Thoughts?

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/11/2017 at 23:02 Ludovic Courtès writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> On 11/10/2017 at 00:04 Ludovic Courtès writes:
>>>
>>> Thrilled by this idea, I pushed an unbound-variable handler that can
>>> provide hints, such as:
>>>
>>>   configuration.scm:88:19: zip: unbound variable
>>>   hint: Try adding `(use-modules (gnu packages compression))'.
>>>
>>> Feedback welcome!
>>
>> I built and played with this.  If I follow some of the hints literally
>> they lead me astray. Here are some suggested hint rewording.
>
> Again, it’s a hint, it could be wrong.
>
> So perhaps that’s a good reason for “Did you mean xyz?”, ending with a
> question mark (like GCC does), rather than a sentence that looks
> assertive.
>
> In the example above, it may be less confusing if we write:
>
>   Did you forget (use-modules …)?
>
> With the question mark, the user understands that this may or may not be
> the cause of the error.
>
> Thoughts?
>
Hi Ludo’,

I have lost your context here. But if you mean that in e.g., ...

>  *** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED"
>
> The error messages ...
>
> /root/ctest/test2:4:0: error: module (gnu packages qemu) not found
> hint: Try adding `(use-package-modules virtualization)'.
>
> ... are followed literally in test2.fix, which does not fix the
> problem because the stale and non-existant 'qemu' package module
> reference also needs to be removed.
>
> Maybe a better hint would be ...
>
> hint: Remove the reference to the pachage module that was not 
> hint: found and add `(use-package-modules virtualization)'.

... something like ... 

hint: Did you remove reference to package module that was not found?
hint: Did you forget `(use-package-modules virtualization)'?

... may be less confusing ...  I agree.  HTH - George

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> ... something like ... 
>
> hint: Did you remove reference to package module that was not found?
> hint: Did you forget `(use-package-modules virtualization)'?

OK, I’ve made this change (“Did you forget” instead of “Try adding”.)

Thanks,
Ludo’.

Re: The usability of Guix configurations

[Hartmut Goebel]

Am 07.11.2017 um 14:13 schrieb julien lepiller:
> This new version outputs something like this : 

Thanks

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#29072: The usability of Guix configurations

[myglc2]

Please note: these replies are separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
[...]
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.

I didn't mean this point critically. Rather as a statement of fact. When
I said ...

>> Could we improve this situation by adding config troubleshooting
>> guidance to the doc?

... I was thinking something like ...

vvvvvvvvvvvvvvvvvv

Troubleshooting your config file:

If you get an error like:

ice-9/boot-9.scm:[...] no code for module (gnu packages <package name>)

You have either specified a package name that does not exist, or your
(use-package-modules <package module names>) does not contain the name
of a package module that contains the definition of <package name>.

You can determine which, if any, module contains a package definition by
yada yada yada

^^^^^^^^^^^^^^^^^^

... thinking that then there would be a search hit in the doc for 'no
code for module' which might enable some users to understand what they
are doing wrong.

WDYT? - George

Re: The usability of Guix configurations

[myglc2]

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>> 
>> Confronted with my situation, helpful developers said "The package code
>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>> config (Efraim)."
>
> I'm sorry that my comment was not enough on its own!
>
>> Once I understood what had happened I wondered, "Gee, I have been using
>> guix for 18 months so why didn't I figure this out myself." ;-)
>> 
>> But a less committed user might say, "Wow, Guix breaks at random, error
>> messages are hard to understand, and support is difficult."  :-(
>
> Good point.
>
>> ISTM this raises issues and questions about Guix configuration
>> usability:
>
> Indeed.
>
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.
[...]
>
>> Guix config errors consume meaningful amounts of user and support
>> effort. I say this because a) it took quite a few iterations to figure
>> out what was wrong in my situation, and b) google search for '"no code
>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>> number of Guix users unless something is done. So I wonder, could an
>> error handler that translates into more user-friendly terms reduce user
>> frustration, increase the rate of user self help, reduce support load,
>> and effectively pay for itself?
>
> That would be awesome!
>
>> Are the current Guix config errors usable by the average GNU/Linux
>> distribution user? If not, don't they need to be improved before we call
>> it 1.0?
>
> Based on how much time it's possible to spend on IRC helping people, I'd
> say there is lots of room for improvement in this area.
>
>> Does this mean that package code must not be moved after 1.0?
>
> A couple thoughts... it would be nice if the GuixSD configuration
> example templates used a filename agnostic method of resolving module
> imports. I'm not a strong enough Schemer to evaluate the situation or
> suggest a solution, but I think that the filenames should not be
> relevant at that level. Perhaps one could use
> 'specification->package+output',
> as demonstrated in the documentation of package manifests:
>
> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
>
There is a parallel solution 
>> Finally: Should I close bug#29072? ;-)
>
> The problem of the missing QEMU patch is resolved. The broader issue of
> confusing error messages could be continued here, or elsewhere. It's up
> to you :)

Re: The usability of Guix configurations

[myglc2]

Sorry Leo, please disregard this miss-fire

On 11/06/2017 at 21:30 myglc2 writes:

> On 11/06/2017 at 17:16 Leo Famulari writes:
>
>> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>>> My system recently broke when I did an upgrade. I reported what I
>>> thought was a bug (bug#29072) but it turned out that, because qemu
>>> package code had been moved, my system configuration had become broken
>>> ;-(
>>> 
>>> Confronted with my situation, helpful developers said "The package code
>>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>>> config (Efraim)."
>>
>> I'm sorry that my comment was not enough on its own!
>>
>>> Once I understood what had happened I wondered, "Gee, I have been using
>>> guix for 18 months so why didn't I figure this out myself." ;-)
>>> 
>>> But a less committed user might say, "Wow, Guix breaks at random, error
>>> messages are hard to understand, and support is difficult."  :-(
>>
>> Good point.
>>
>>> ISTM this raises issues and questions about Guix configuration
>>> usability:
>>
>> Indeed.
>>
>>> Guix config errors are reported as raw scheme errors which are not
>>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>>> situation by adding config troubleshooting guidance to the doc?
>>
>> Yes, we do try to add helpful error messages, although obviously there
>> is a lot more work to be done.
> [...]
>>
>>> Guix config errors consume meaningful amounts of user and support
>>> effort. I say this because a) it took quite a few iterations to figure
>>> out what was wrong in my situation, and b) google search for '"no code
>>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>>> number of Guix users unless something is done. So I wonder, could an
>>> error handler that translates into more user-friendly terms reduce user
>>> frustration, increase the rate of user self help, reduce support load,
>>> and effectively pay for itself?
>>
>> That would be awesome!
>>
>>> Are the current Guix config errors usable by the average GNU/Linux
>>> distribution user? If not, don't they need to be improved before we call
>>> it 1.0?
>>
>> Based on how much time it's possible to spend on IRC helping people, I'd
>> say there is lots of room for improvement in this area.
>>
>>> Does this mean that package code must not be moved after 1.0?
>>
>> A couple thoughts... it would be nice if the GuixSD configuration
>> example templates used a filename agnostic method of resolving module
>> imports. I'm not a strong enough Schemer to evaluate the situation or
>> suggest a solution, but I think that the filenames should not be
>> relevant at that level. Perhaps one could use
>> 'specification->package+output',
>> as demonstrated in the documentation of package manifests:
>>
>> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
>>
> There is a parallel solution 
>>> Finally: Should I close bug#29072? ;-)
>>
>> The problem of the missing QEMU patch is resolved. The broader issue of
>> confusing error messages could be continued here, or elsewhere. It's up
>> to you :)

bug#29072: The usability of Guix configurations

[myglc2]

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>> 
>> Confronted with my situation, helpful developers said "The package code
>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>> config (Efraim)."
>
> I'm sorry that my comment was not enough on its own!
>
>> Once I understood what had happened I wondered, "Gee, I have been using
>> guix for 18 months so why didn't I figure this out myself." ;-)
>> 
>> But a less committed user might say, "Wow, Guix breaks at random, error
>> messages are hard to understand, and support is difficult."  :-(
>
> Good point.
>
>> ISTM this raises issues and questions about Guix configuration
>> usability:
>
> Indeed.
>
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.
[...]
>
>> Guix config errors consume meaningful amounts of user and support
>> effort. I say this because a) it took quite a few iterations to figure
>> out what was wrong in my situation, and b) google search for '"no code
>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>> number of Guix users unless something is done. So I wonder, could an
>> error handler that translates into more user-friendly terms reduce user
>> frustration, increase the rate of user self help, reduce support load,
>> and effectively pay for itself?
>
> That would be awesome!
>
>> Are the current Guix config errors usable by the average GNU/Linux
>> distribution user? If not, don't they need to be improved before we call
>> it 1.0?
>
> Based on how much time it's possible to spend on IRC helping people, I'd
> say there is lots of room for improvement in this area.
>
>> Does this mean that package code must not be moved after 1.0?
>
> A couple thoughts... it would be nice if the GuixSD configuration
> example templates used a filename agnostic method of resolving module
> imports. I'm not a strong enough Schemer to evaluate the situation or
> suggest a solution, but I think that the filenames should not be
> relevant at that level. Perhaps one could use
> 'specification->package+output',
> as demonstrated in the documentation of package manifests:
>
> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
>
There is a parallel solution 
>> Finally: Should I close bug#29072? ;-)
>
> The problem of the missing QEMU patch is resolved. The broader issue of
> confusing error messages could be continued here, or elsewhere. It's up
> to you :)

Re: The usability of Guix configurations

[myglc2]

Please note: these replies are separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
[...]
> As far as I can tell, the issue was related to the fact that you are
> using Guix by building it from source and re-using the same build
> directory, which may contain stale compiled .go files. In this case,
> there was a leftover qemu.go, which shadowed the correct file,
> virtualization.go.
>
> This is a useful development technique but not how Guix is supposed to
> be deployed and updated. `guix pull && guix package --upgrade` is still
> what we recommend and support.

Yes, the initial issue as I reported and labeled it was caused by
building from source and the fact that 'make clean-go' unexpectedly (at
least to me) left stale files laying around. But if 'make clean-go' had
nuked all the .go files as I expected, or if I had been using guix pull,
I would still have experienced the configuration breakage caused by the
qemu package being moved from ./gnu/packages/qemu.scm to
./gnu/packages/virtualization.scm which produced the error messages that
befuddled me and which are the primary focus in this post.

> If you want to deploy Guix by building it "by hand", I recommend using
> a fresh Git checkout and directory each time you build it. That way,
> you can be sure to avoid this class of error (stale module references
> in leftover .go files), which is well-known to the seasoned Guix
> developers but totally confounding for everyone else.

That sounds really inconvenient and would not fit my mode of use (for
details on my mode of use and how I see stale files, please this post:

http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html

Can you tell me what the benefit to developers are, if any, of keeping
stale .go files around?

TIA - George

Re: The usability of Guix configurations

[myglc2]

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade.
[...] replied to separately
>> because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>>
[...] replied to separately
>> 
>> But a less committed user might say, "Wow, Guix breaks at random, error
>> messages are hard to understand, and support is difficult."  :-(
>
> Good point.
>
>> ISTM this raises issues and questions about Guix configuration
>> usability:
>
> Indeed.
>
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>>
[...] replied to separately
>>
>> Guix config errors consume meaningful amounts of user and support
>> effort. I say this because a) it took quite a few iterations to figure
>> out what was wrong in my situation, and b) google search for '"no code
>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>> number of Guix users unless something is done. So I wonder, could an
>> error handler that translates into more user-friendly terms reduce user
>> frustration, increase the rate of user self help, reduce support load,
>> and effectively pay for itself?
>
> That would be awesome!
>
>> Are the current Guix config errors usable by the average GNU/Linux
>> distribution user? If not, don't they need to be improved before we call
>> it 1.0?
>
> Based on how much time it's possible to spend on IRC helping people, I'd
> say there is lots of room for improvement in this area.
>
>> Does this mean that package code must not be moved after 1.0?

Note: On a sub-thred, julien lepiller has proposed a patch that, IMO,
improves these errors and should enable users to help themselves more.

> A couple thoughts... it would be nice if the GuixSD configuration
> example templates used a filename agnostic method of resolving module
> imports. I'm not a strong enough Schemer to evaluate the situation or
> suggest a solution, but I think that the filenames should not be
> relevant at that level. Perhaps one could use
> 'specification->package+output',
> as demonstrated in the documentation of package manifests:
>
> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

I agree. I didn't realize until looking at the 0.13.0.4499-17480 doc
today that ...

     (use-modules (gnu packages))
     (operating-system
       ;; ...
       (packages (append (map specification->package
                              '("tcpdump" "htop" "gnupg@2.0"))
                         %base-packages)))

... is available in system configs. I currently use ...

     (use-modules (gnu packages))
     (specifications->manifest
         '("emacs" "guile@2.2" "guile@2.2:debug"))

... in manifests.

And, to your point, ISTM that if the manual and templates were revised
to present these as the cannonical guix configuration methods in all
examples and templates, guix config usability would be dramatically
improved.

Is this feasible to do?

If we go down this path, ISTM it would be helpful to users for ...

https://www.gnu.org/software/guix/packages/

... to provide valid text string(s) for each available package.

>> Finally: Should I close bug#29072? ;-)
>
> The problem of the missing QEMU patch is resolved. The broader issue of
> confusing error messages could be continued here, or elsewhere. It's up
> to you :)

OK, Thanks, I will close the bug.

bug#29072: The usability of Guix configurations

[Ludovic Courtès]

Hello,

myglc2 <myglc2@gmail.com> skribis:

> My system recently broke when I did an upgrade. I reported what I
> thought was a bug (bug#29072) but it turned out that, because qemu
> package code had been moved, my system configuration had become broken
> ;-(

It should be noted that you were using a “developer setup”, specifically
running Guix from a checkout with ./pre-inst-env and all.

The issue with the stale module wouldn’t happen with “guix pull”, which
is the recommended “user setup.”

While I agree the situation is not ideal, I think we have to admit that
developers can always shoot themselves in the foot, and that was one way
of doing it.  ;-)

Thoughts?

Ludo’.

Re: The usability of Guix configurations

[Ludovic Courtès]

Hello,

myglc2 <myglc2@gmail.com> skribis:

> My system recently broke when I did an upgrade. I reported what I
> thought was a bug (bug#29072) but it turned out that, because qemu
> package code had been moved, my system configuration had become broken
> ;-(

It should be noted that you were using a “developer setup”, specifically
running Guix from a checkout with ./pre-inst-env and all.

The issue with the stale module wouldn’t happen with “guix pull”, which
is the recommended “user setup.”

While I agree the situation is not ideal, I think we have to admit that
developers can always shoot themselves in the foot, and that was one way
of doing it.  ;-)

Thoughts?

Ludo’.

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 11:23 Ludovic Courtès writes:

> Hello,
>
> myglc2 <myglc2@gmail.com> skribis:
>
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>
> It should be noted that you were using a “developer setup”, specifically
> running Guix from a checkout with ./pre-inst-env and all.
>
> The issue with the stale module wouldn’t happen with “guix pull”, which
> is the recommended “user setup.”
>
> While I agree the situation is not ideal, I think we have to admit that
> developers can always shoot themselves in the foot, and that was one way
> of doing it.  ;-)
>
> Thoughts?
>
> Ludo’.

I think I misinterpreted this earlier as dismissing the usability
points.  Now I think you are referring to the bug specifically, and from
that point of view I agree. I have closed the bug as notabug.

I posted thoughts/questions re use of "developer setup" by users and
'make clean-go' here ...

http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html

Best - George

bug#29072: guix system: error: qemu-CVE-2017-7493.patch: patch not found

[myglc2]

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

After a clean guix make, guix system build produced this error ...

root@g1 ~/con/15# guix system --cores=4 --max-jobs=4 -K --on-error=debug build sys.scm
guix system: error: qemu-CVE-2017-7493.patch: patch not found

VERSION INFO:

root@g1 ~/con/15# guix --version
guix (GNU Guix) 0.13.0.4202-1f6f4
Copyright (C) 2017 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

root@g1 ~/con/15# stat ~/.config/guix/latest | grep File:
  File: /root/.config/guix/latest -> /home/g1/src/guix/

root@g1 ~/con/15# git -C ~/.config/guix/latest describe
v0.13.0-4202-g1f6f4c40c

root@g1 ~/con/15# git -C ~/.config/guix/latest log -n 1 --oneline
1f6f4c40c (HEAD -> o-master, origin/master, origin/HEAD) gnu: Add r-tgconfig.

root@g1 ~/con/15# git -C /home/g1/src/guix branch -av | grep '*'
* o-master                                1f6f4c40c gnu: Add r-tgconfig.

SYS CONFIG:


[-- Attachment #2: sys.scm --]
[-- Type: application/octet-stream, Size: 2043 bytes --]

;;; GuixSD headless server
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules
 admin
 base
 certs
 cups
 disk
 emacs
 freeipmi
 linux
 qemu
 rsync
 screen
 ssh
 version-control
 wget
 xorg 
 )
(operating-system
  (host-name "g1")
  (timezone "America/New_York")
  (locale "en_US.utf8")
  (kernel-arguments '("console=ttyS1,115200"))
  ;; RAID1 root using 1 NVMe SSD + 2 HDs
  (bootloader (grub-configuration (target "/dev/nvme0n1")
				  (terminal-outputs '(console))
				  (terminal-inputs '(serial console))
				  (serial-speed 115200)				  
				  ))
  (initrd (lambda (file-systems . rest) (apply base-initrd file-systems
					       #:extra-modules '("raid1")
					       rest)))
  (mapped-devices (list (mapped-device
			 (source '("/dev/nvme0n1p1" "/dev/sda1" "/dev/sdb1"))
			 (target "/dev/md3")
			 (type raid-device-mapping))))
  (file-systems (cons (file-system
			(title 'device)
			(device "/dev/md3")
			(mount-point "/")
			(type "ext4")
			(dependencies mapped-devices))
		      %base-file-systems))
  (swap-devices '("/dev/nvme0n1p2" ))
  (users (cons* (user-account (name "g1")
			      (group "users")
			      (supplementary-groups '("wheel" "kvm"))
			      (home-directory (string-append "/home/" name)))
		(user-account (name "admin")
			      (group "users")
			      (supplementary-groups '("wheel" "kvm"))
			      (home-directory (string-append "/home/" name)))
		%base-user-accounts))
  (packages (cons*
	     cups
	     emacs-no-x-toolkit
	     emacs-guix
	     emacs-zenburn-theme
	     freeipmi
	     git
	     glibc-utf8-locales
	     gnu-make
	     mdadm
	     magit
	     nss-certs
	     openssh
	     parted
	     qemu
	     rsync
	     screen
	     smartmontools
	     tree
	     wget
	     xauth
	     %base-packages))
  (services (cons* (dhcp-client-service)
		   (ntp-service)
		   (service openssh-service-type (openssh-configuration
						  (x11-forwarding? #t)))
		   (agetty-service (agetty-configuration (tty "ttyS1")
							 (baud-rate "115200")))
		   %base-services)))

bug#29072: The usability of Guix configurations

[myglc2]

My system recently broke when I did an upgrade. I reported what I
thought was a bug (bug#29072) but it turned out that, because qemu
package code had been moved, my system configuration had become broken
;-(

Confronted with my situation, helpful developers said "The package code
was moved in commit xxx" (Leo) and "maybe you have a mistake in your
config (Efraim)."

Once I understood what had happened I wondered, "Gee, I have been using
guix for 18 months so why didn't I figure this out myself." ;-)

But a less committed user might say, "Wow, Guix breaks at random, error
messages are hard to understand, and support is difficult."  :-(

ISTM this raises issues and questions about Guix configuration
usability:

Guix config errors are reported as raw scheme errors which are not
user-friendly, except, perhaps, to guile users ;-) Could we improve this
situation by adding config troubleshooting guidance to the doc?

Guix config errors consume meaningful amounts of user and support
effort. I say this because a) it took quite a few iterations to figure
out what was wrong in my situation, and b) google search for '"no code
for module" guix' finds 613 hits, which will no doubt grow linearly with
number of Guix users unless something is done. So I wonder, could an
error handler that translates into more user-friendly terms reduce user
frustration, increase the rate of user self help, reduce support load,
and effectively pay for itself?

Are the current Guix config errors usable by the average GNU/Linux
distribution user? If not, don't they need to be improved before we call
it 1.0?
        
Does this mean that package code must not be moved after 1.0?

Finally: Should I close bug#29072? ;-)