[bug#70830] [PATCH] doc: Document assume-valid-file-name in local-file

[bug#70830] [PATCH] doc: Document assume-valid-file-name in local-file

[Richard Sent]

doc/guix.texi (G-Expressions): Document the use of assume-valid-file-name with
local-file.
---
Hi Guix!

I found it odd that assume-valid-file-name isn't documented in the
manual. Well, now it is!

 doc/guix.texi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1c1e0164e7..221db5c022 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -12154,6 +12154,18 @@ G-Expressions
 absolute file name and @var{stat} is the result of @code{lstat}; exclude
 entries for which @var{select?} does not return true.
 
+@var{file} can be wrapped in the @code{assume-valid-file-name} syntactic
+keyword. When this is done, there will not be a warning when
+@code{local-file} is used with a non-literal path.  The path is still
+looked up relative to the current working directory at run time.
+Wrapping is done like this:
+
+@lisp
+(define alice-key-file-path "alice.pub")
+;; ...
+(local-file (assume-valid-file-name alice-key-file-path))
+@end lisp
+
 This is the declarative counterpart of the @code{interned-file} monadic
 procedure (@pxref{The Store Monad, @code{interned-file}}).
 @end deffn

base-commit: da41a8f5e85774e2a507d821b5d52e600fb9d1d7
-- 
2.41.0

[bug#70830] Resending as a series

[Richard Sent]

I submitted another patch (https://qa.guix.gnu.org/issue/70829) which
accidentally depends on this one. I'll resubmit to that issue as a
series since the documentation changes are tied together a bit anyway.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

[bug#70830] [PATCH] doc: Document assume-valid-file-name in local-file

[Ludovic Courtès]

Hi,

Richard Sent <richard@freakingpenguin.com> skribis:

> doc/guix.texi (G-Expressions): Document the use of assume-valid-file-name with
> local-file.

Applied, thanks!

Ludo’.

[bug#70830] [PATCH] doc: Document assume-valid-file-name in local-file

[Richard Sent]

Hi Ludo!

>> I submitted another patch (https://qa.guix.gnu.org/issue/70829)which
>> accidentally depends on this one. I'll resubmit to that issue as a
>> series since the documentation changes are tied together a bit
>> anyway.

Will applying this patch mess up 70829? My intent was to close 70830 and
combine it with 70829, although if the other changes in 70829 aren't
deemed suitable for a merge then there's no need to worry.

Thanks!

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.