unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny O'Brien <danny@spesh.com>
To: Brendan Tildesley <mail@brendan.scot>
Cc: guix-devel@gnu.org
Subject: Re: ‘guix environment’ vs. ‘.bash_profile’
Date: Sun, 13 Sep 2020 14:22:14 -0700	[thread overview]
Message-ID: <874ko14bjt.fsf@spesh.com> (raw)
In-Reply-To: <ada92bf2-f957-fc19-2361-f9727655c700@brendan.scot>


Brendan Tildesley <mail@brendan.scot> writes:

> Doom Emacs has a tool `doom doctor' for diagnosing common 
> errors. Perhaps there
> could be a `guix doctor' that would check for such things. `guix 
> offload test'
> is already somewhat like that but for offloading, althought it 
> could improve.
> Any bug report from a user where the solution is to tell them to 
> fix their
> environment instead of changing guix could also have a check 
> added to guix
> doctor. Also, we could collect knowledge on aspects of GNU/Linux 
> that are unique
> to Guix that one often doesn't learn about on other 
> distributions and include a
> page in the manual. for example I never had any use for sudo -E 
> or sudo -i
> until I started using Guix.
>

I was going to suggest the same thing -- a "guix doctor" would 
have
helped me a great deal when I was struggling to set up guix at the 
very
start.

Also because I share my shell and other configuration files across
distributions, it's not uncommon for me to fix something in 
another
distribution which causes repeated trouble in guix (or 
vice-versa!). So
a program that I could repeatedly re-run to identify a root cause 
(or
even run as a test to check that a change doesn't break guix) 
would be
great. Just something that can tell you "oh, your environment 
variables
aren't what I would expect, here is what I think may be wrong" 
would be
very useful.

Another quick note: I've noticed a trend in a few FLOSS projects 
of
spending some concentrated time on improving the usability of 
error
messages. Elm and Rust are two examples that spring to mind. The
strategy appears to be to collect common mistakes and their 
errors, and
then iterate on making the error messages not only clearer about 
what
has happened, but also provide concrete suggestions on what can be 
done
to fix the problem -- to the extent of even providing suggested 
commands
that would correct the error.

https://elm-lang.org/news/compiler-errors-for-humans

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

I find Guix error messages to be very good on the whole, but I 
wonder if
the strong connection between Guix and Guile might serve us well 
here.
Clearer error messages in the REPL, informed by Guix usage and
implemented by improving Guile error reporting, would benefit both
immensely. And I think it might makes sense to do this in tandem 
with a
more reactive "guix doctor" project.

I'm not a great coder, but I make a lot of common mistakes, so 
happy to
help in that respect!

d.


  reply	other threads:[~2020-09-13 21:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-13  5:24 ‘guix environment’ vs. ‘.bash_profile’ Brendan Tildesley
2020-09-13 21:22 ` Danny O'Brien [this message]
2020-09-16 16:47   ` Ludovic Courtès
2020-09-16 17:58     ` Ricardo Wurmus
2020-09-16 20:17   ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2020-09-12 12:49 Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874ko14bjt.fsf@spesh.com \
    --to=danny@spesh.com \
    --cc=guix-devel@gnu.org \
    --cc=mail@brendan.scot \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).