guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dissecting Guix -- blog post series


From: (
Subject: Re: Dissecting Guix -- blog post series
Date: Sun, 11 Dec 2022 10:08:54 +0000

Heya,

On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:
> I think it'd also be fine to come up with the titles during the process of 
> writing as sometimes that process itself is insightful. E.g. I could imagine 
> parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

Perhaps.  I think monads are complex enough to warrant their own post, though.

> How'd this part differ from section "12.18 Defining Services" of the manual?

Along with a low-level description of the workings of services, it'd contain a
complex, concrete example of a service.  The manual mostly has an API reference
and some high-level-ish examples.

> How'd this part differ from sections 22 and "22.6 Submitting Patches" from 
> the manual?

Again, it'd be more concrete than what the manual shows.  It'd explain the
process by demonstrating the development of an *actual patch*, and showing how
it could be sent to guix-patches@gnu.org.

> By the way, the text does not seem to strictly fill columns at a certain line 
> width. So I did not bother to fill columns in the "patch".

Right, I should set up FILL-COLUMNS-INDICATOR... :)

> If the purpose is out of scope, then we should not dive in that deeply. 
> Especially, I'd suggest skip the code snippet.

I'm not sure about this.  

> Here you write "pretty simple". Later you also write "self-explanatory" and 
> "obviously". I suggest to let the reader decide what's simple.

Fair.

> Before this point, the record fields have been called '"argument"'s all the 
> time. I think it's not nice style to carry on a quoted term through many 
> paragraphs like this. Let's simply write "record field" all the time, instead.

This is fair too :)

> I think an example for invoking read-derivation-from-file would round up this 
> tutorial really nicely because it'd close the circle between .drv-files and 
> <derivation>-objects.

Okay!  And one for write-derivation, too.

> Here, in the conclusion, IMHO, there could be another brief listing of all 
> fields of a derivation.

Good idea.

    -- (

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]