ludo@gnu.org (Ludovic Courtès) writes:
> Usually files resulting from a checkout are read-only, so perhaps you
> need to make a bunch of files writable before the ‘check’ phase.  For a
> start you could do:
>
>   (for-each make-file-writable (find-files "tests"))

Damn, bitten by this again!  It's not the first time and it seems that I fail to
learn from my mistakes :p

I've modified the 'unpack phase instead to avoid changing directory:

--8<---------------cut here---------------start------------->8---
           (add-after 'unpack 'make-files-writable-for-tests
               (lambda _ (for-each make-file-writable (find-files "."
           ".*")))))))
--8<---------------cut here---------------end--------------->8---

It works now, thanks!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
> * I wonder if maybe we should avoid using “guix package” for the first
>   example and use “guix build” instead.  The reason is that “guix
>   package” might cause additional builds to be performed dependent on
>   the state of the user’s default profile (because of profile hooks).
>   Using “guix build” bypasses this issue completely.  What do you think?

Hmm... Installing a package is something more familiar than just "building".
Besides, with the new "cleaner" output, it's only a few lines which the user is
going to see all the time, so I don't think there is much complexity we can
trim here.

If we first build, then package, it makes the "easy" example an extra step more
complicated.

> * “Create a folder” –> “Create a directory”; “folder” is a GUI metaphor,
>   but that’s nitpicking to be fair.  I prefer “directory”, but use
>   “folder” if you find it better :)

Funny, I did not know that :p What is the GUI metaphor precisely?  I personally
prefer "folder" for the simple reason that it's shorter, but I don't mind
changing ;)

>   This is usually true, but the meaning of “native-inputs” is primarily
>   important for cross-building packages.  A native input will be used on
>   the build machine and should thus be available for the build machine’s
>   architecture, not for the target machine.  Since Guix scans for
>   references, packages that are only needed at build time will not be
>   installed even when they are among the plain “inputs”.  Likewise,
>   packages that are in the “native-inputs” may end up leaving a
>   reference behind, which will cause them to be downloaded.  (This is
>   often a bug, such as in the icedtea packages, which keep unwanted
>   references.)
>
>   Not sure if we should change this in the tutorial, because it’s a
>   finer point.  The distinction between inputs and propagated-inputs is
>   more important and I think it’s done well in your draft.

Indeed, I think it's too complicated at this stage.  Case in point, your
paragraph is quite long ;)  I'd rather skip this.

> * I don’t know if there should be a section “Common pitfalls and best
>   practices” other than to point to the checklist in the manual.  If the
>   list in the manual misses one of the points I’d rather add them there
>   and only link to the list.

I agree.  I'll merge this list with the manual then.

> * The section on “Recursive importers” does not mention any recursive
>   importers :)  How about using the CRAN importer here, which supports
>   recursive importing with the “-r” option?

Hmm... I can't get this to work.

--8<---------------cut here---------------start------------->8---
guix import cran --recursive lubridate
--8<---------------cut here---------------end--------------->8---

returns only one package.  In fact, the "-r,--recursive" flag is missing from
the `guix import cran -h` documentation (while it's there for pipy).  I cannot
get it to work for pipy either.

Do you have a working example?

I've applied all you other suggestions.  Thank you Ricardo for this second
thorough review!

-- 
Pierre Neidhardt
https://ambrevar.xyz/