Re: The usability of Guix configurations

[myglc2 <myglc2@gmail.com>]

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.