unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Danny O'Brien <danny@spesh.com>
Cc: guix-devel@gnu.org, Brendan Tildesley <mail@brendan.scot>
Subject: Re: ‘guix environment’ vs. ‘.bash_profile’
Date: Wed, 16 Sep 2020 18:47:30 +0200
Message-ID: <87363hmzx9.fsf@gnu.org> (raw)
In-Reply-To: <874ko14bjt.fsf@spesh.com> (Danny O'Brien's message of "Sun, 13 Sep 2020 14:22:14 -0700")

Hi!

Danny O'Brien <danny@spesh.com> skribis:

> 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.

Interesting.  Any idea how this particular issue could be checked for?
If we can come up with an automated way to determine that “something’s
wrong”, we might as well get ‘guix environment’ to display a hint.

> 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.

I see.

> 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

Yes, I very much admire what the Elm folks (and also the GCC folks,
closer to me) have achieved in recent years.

> 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.

We’ve tried to follow the trend above.  :-)  We’re still very far from
the quality of Elm or recent GCC messages, but I think that, as you
write, we can iterate on specific error messages and gradually improve
them, add hints, and so on.

For example, ‘guix’ displays hints for unbound variables or misnamed
modules because these are common mistakes.  Let’s collect more of those
“common mistakes” and improve the way they are reported.

Thanks,
Ludo’.


  reply	other threads:[~2020-09-16 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-13  5:24 Brendan Tildesley
2020-09-13 21:22 ` Danny O'Brien
2020-09-16 16:47   ` Ludovic Courtès [this message]
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=87363hmzx9.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=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

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git