all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Leo Famulari <leo@famulari.name>
Cc: 53224@debbugs.gnu.org, Matt <matt@excalamus.com>
Subject: bug#53224: Cookbook recipe about profile collisions
Date: Mon, 17 Jan 2022 15:16:28 +0100	[thread overview]
Message-ID: <87pmoqo3b7.fsf@gnu.org> (raw)
In-Reply-To: <YeHCZgO5c+I36Flr@jasmine.lan> (Leo Famulari's message of "Fri, 14 Jan 2022 13:35:18 -0500")

Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

> I pointed to this blog post, which was linked from that email:
>
>> > Specifically see this blog post:
>> > http://excalamus.com/2021-10-06-guix-debug.html
>
> It's the story of an attempt to learn what the "conflicting entries"
> message means and how to resolve it.

Oh sorry, I had overlooked this.  It makes perfect sense now, and this
blog post is useful in understand what it feels like to encounter that
error message for the first time.

>> Currently, on profile collisions, the error message shows where the
>> collision originates and a hint on how to work around it.  Perhaps the
>> hint is sometimes wrong (in which cases?), or perhaps it’s too terse?
>> Can it be improved?
>
> The hint is perfectly clear, when you understand "profiles" and
> "propagation".
>
> It's like I said later in my message: People use Guix without knowing
> very much about it.
>
> That's surprising to me, because I started using Guix *because* I
> learned about profiles and how they are used: it's one of the core
> innovations of Guix / Nix, to implement unprivileged package management.
>
> But nevertheless, people are using Guix without understanding how it
> works. And it's hard to learn about Guix when you are dealing with a
> profile collision that you don't understand at all. For many people,
> that is not a good moment to start learning. On top of that, profile
> collisions are an error state that we can't fix as a bug: we have to
> give users the knowledge to resolve the collisions themselves.

Yeah.  So, given that “profile” is already defined in “Getting Started”,
I think we can’t do a lot more in the manual.

However, as a way of helping users incrementally discover concepts they
need to understand, we could use one-time hints (sorta like the “Did you
know?” boxes in GUIs.)  ‘guix shell’ already uses a one-time hint
inviting users to run ‘--check’.

We could imagine that the first run of ‘guix install’ & co. would print
a message explaining that your packages’ files are now in
~/.guix-profile, and that it’s what we call a “profile”.

Would that make sense?

> For example, the blog post that I linked to ends with "Lessons Learned",
> which includes this:
>
> ------
> What is a profile?
>
> A profile is a directory of symlinks located at ~/.guix-profile.
>
> Propagated inputs can cause conflicts
>
> Propagated inputs are treated somehow differently. It's still not 100%
> clear how or why, but it's good to know they're a potential source of
> errors.
> ------
>
> This person spent a lot of time trying to understand the situation and
> writing the blog post, but their understanding is still rather weak.

To be fair, the person didn’t look for “profile” in the manual.  I’m not
blaming—mentioning it to clarify what it is we’re trying to fix.

> That's why I propose a Cookbook chapter that specifically addresses
> profile collisions, to help new users go from "oh no, an error message"
> to "aha!"

Makes sense!

>> In some early talks we had illustrations of the symlink forest of a
>> profile borrowed from Eelco Dolstra’s own talks on the matter; see for
>> instance p. 17 of <https://guix.gnu.org/guix-fosdem-20140201.pdf>.  I

[...]

> The illustrations of the symlink forest were *extremely* helpful to me
> when learning how Guix implements unprivileged package management. I
> think that later talks from the 2015-2017 era refined the illustrations
> to be even more clear.

OK, let’s see if we can include an illustration like that under
“Managing Software the Guix Way” or something like that.

> I'm sorry if the use case for my proposal is still unclear. I can work
> on the Cookbook chapter myself.

Great, thanks.

Ludo’.




  reply	other threads:[~2022-01-17 14:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13  0:11 bug#53224: Cookbook recipe about profile collisions Leo Famulari
2022-01-14  8:47 ` Ludovic Courtès
2022-01-14 12:02   ` zimoun
2022-01-14 18:35   ` Leo Famulari
2022-01-17 14:16     ` Ludovic Courtès [this message]
2022-01-17 17:56       ` Profile definition, was " Matt
2022-01-17 18:40         ` Leo Famulari
2022-01-18 15:36           ` Ludovic Courtès
2022-01-19  2:41             ` Matt

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

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

  git send-email \
    --in-reply-to=87pmoqo3b7.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=53224@debbugs.gnu.org \
    --cc=leo@famulari.name \
    --cc=matt@excalamus.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.