From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gEdZJcZBYl/PGAAA0tVLHw (envelope-from ) for ; Wed, 16 Sep 2020 16:48:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id YIRFIcZBYl94EgAAB5/wlQ (envelope-from ) for ; Wed, 16 Sep 2020 16:48:06 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1B071940703 for ; Wed, 16 Sep 2020 16:48:06 +0000 (UTC) Received: from localhost ([::1]:51104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIabE-0002x2-UR for larch@yhetil.org; Wed, 16 Sep 2020 12:48:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kIaaw-0002vS-8t for guix-devel@gnu.org; Wed, 16 Sep 2020 12:47:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44789) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIaau-0004LS-5C; Wed, 16 Sep 2020 12:47:44 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39800 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kIaat-0002FT-NF; Wed, 16 Sep 2020 12:47:43 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Danny O'Brien Subject: Re: =?utf-8?Q?=E2=80=98guix_environment=E2=80=99?= vs. =?utf-8?Q?=E2=80=98=2Ebash=5Fprofile=E2=80=99?= References: <874ko14bjt.fsf@spesh.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Jour de la Vertu de =?utf-8?Q?l'Ann=C3=A9e?= 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 16 Sep 2020 18:47:30 +0200 In-Reply-To: <874ko14bjt.fsf@spesh.com> (Danny O'Brien's message of "Sun, 13 Sep 2020 14:22:14 -0700") Message-ID: <87363hmzx9.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Brendan Tildesley Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: 2SvyzeTC3tVW Hi! Danny O'Brien skribis: > Brendan Tildesley 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 =E2=80=9Csomethin= g=E2=80=99s wrong=E2=80=9D, we might as well get =E2=80=98guix environment=E2=80=99 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=E2=80=99ve tried to follow the trend above. :-) We=E2=80=99re still ve= ry 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, =E2=80=98guix=E2=80=99 displays hints for unbound variables or= misnamed modules because these are common mistakes. Let=E2=80=99s collect more of t= hose =E2=80=9Ccommon mistakes=E2=80=9D and improve the way they are reported. Thanks, Ludo=E2=80=99.