Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:

On 06-08-2022 08:55, Liliana Marie Prikler wrote:

+If your package has a bug that takes multiple lines to fix,

I don't think this is true for replacing all instances of "foo" by 
"/gnu/store/.../bin/foo" in a file.

Should it?

I don't think so. Directly substituting all the instances instead of first writing a patch that does "foo" -> "@foo@" or such seems simpler to me. This might be a bit too nit-picky though, maybe it's clear from context that this is not the kind of fix meant by that line.

+ Furthermore, as with patches, modifying the snippets causes two
derivations to be built.

This is true, but I don't think reviewers and package authors have to
worry about that.

It does make a difference to the author when debugging their package. 
Starting with a phase and then moving it to a snippet can save good
time.

Hm, maybe, I guess I often work on 'small' packages where it doesn't matter much.

On 09-08-2022 19:05, Liliana Marie Prikler wrote:

+Such changes include, but are not limited to, fixes of the build
+script(s) or embeddings of store paths (e.g. [...])

[...]

Is that how to English comma?  Sorry, I'm not a native speaker so I get
somewhat weirded out by the when to skip/not to skip rules.

Neither am I. English doesn't seem to do "rules" much. I do think, however, that adding a comma after "to" makes things a bit simpler to read here, and it doesn't appear to be ungrammatical -- at least, in licenses "but is/are not limited to" is often used that way.

Derivations are a rather low-level concept, could they be avoided in
the origin and phases documentation?

I don't quite see how.  You could s/source derivation/the result of
@code{guix build -S}/, but I don't think that's much better.

To be clear, do you mean you:

think it's not better, maybe even worse
think it's not _much_ better (but still _slightly_ better)
are undecided
or something else

Also, "guix build -S" returns the source code (after snippet / patch, if any), not its derivation. For the latter: "guix build -S -d"

+Build phases are limited in that they do not modify the source
+derivation.  Thus, they are inadequate for changes that are to be
+reflected in the source code.  On the other hand, they only cause
a
+single rebuild and are thus slightly easier to debug than phases
and
+snippets.

See Andreas' comment on phase->snippet.

Also, do I understand correctly that the argument here is that
'single rebuild -> less compilation time -> easier to debug'?

Easier to debug for the package author currently fiddling with the
phase/snippet.  Not really a statement in any direction otherwise.

I don't see how "slightly easier to debug than phases" follows from "they cause only a single rebuild". My guess was that the intermediate step was lower compilation time, but apparently this was not the argument. As such, I'm not following.

Greetings,
Maxime.