[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘guix environment’ vs. ‘.bash_profile’
From: |
Danny O'Brien |
Subject: |
Re: ‘guix environment’ vs. ‘.bash_profile’ |
Date: |
Sun, 13 Sep 2020 14:22:14 -0700 |
User-agent: |
mu4e 1.4.13; emacs 27.1 |
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.