guix-patches
[Top][All Lists]
Advanced

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

[bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell'.


From: Maxim Cournoyer
Subject: [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell'.
Date: Wed, 09 Nov 2022 22:10:38 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hi Ludo!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> That looks like a useful improvement!  Some comments below.

Thanks!

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> +@item --symlink=@var{spec}
>> +@itemx -S @var{spec}
>> +For containers, create the symbolic links specified by @var{spec}, as
>> +documented in @ref{pack-symlink-option}.
>
> We should refrain from using @ref in sentences (info "(texinfo) @ref").
> Instead, I’d write:
>
>   documented for @command{guix pack} (@pxref{pack-symlink-option}).

I've heard that from you before, but is there a reason against?  I like
to know the rationale for doing things a certain way, lest I forget :-).
>From info '(texinfo) @ref':

--8<---------------cut here---------------start------------->8---
6.6 '@ref'
==========

'@ref' is nearly the same as '@xref' except that it does not generate a
'See' in the printed output, just the reference itself.  This makes it
useful as the last part of a sentence.

For example,

     For more information, @pxref{This}, and @ref{That}.

produces in Info:

     For more information, *note This::, and *note That::.
--8<---------------cut here---------------end--------------->8---

>>  (define-module (gnu build install)
>> +  #:use-module ((guix build union) #:select (relative-file-name))
>>    #:use-module (guix build syscalls)
>>    #:use-module (guix build utils)
>>    #:use-module (guix build store-copy)
>> @@ -26,6 +27,7 @@ (define-module (gnu build install)
>>    #:use-module (ice-9 match)
>>    #:export (install-boot-config
>>              evaluate-populate-directive
>> +            make-symlink->directives
>>              populate-root-file-system
>>              install-database-and-gc-roots
>>              populate-single-profile-directory
>> @@ -124,6 +126,22 @@ (define target* (if (string-suffix? "/" target)
>>                  directive)
>>          (apply throw args)))))
>>
>> +(define (make-symlink->directives directory)
>> +  "Return a procedure that turn symlinks specs into directives that target
>> +DIRECTORY."
>> +  (match-lambda
>> +    ((source '-> target)
>> +     (let ((target (string-append directory "/" target))
>> +           (parent (dirname source)))
>> +       ;; Never add a 'directory' directive for "/" so as to preserve its
>> +       ;; ownership and avoid adding the same entries multiple times.
>> +       `(,@(if (string=? parent "/")
>> +               '()
>> +               `((directory ,parent)))
>> +         ;; Note: a relative file name is used for compatibility with
>> +         ;; relocatable packs.
>> +         (,source -> ,(relative-file-name parent target)))))))
>
> I think it’s a case where I would refrain from factorizing because this
> procedure, as shown by the comments and the use of ‘relative-file-name’,
> is specifically tailored for the needs to ‘guix pack -f tarball’.
>
> I’d prefer to have a similar but independently maintained variant of
> this procedure in (guix scripts environment) to avoid difficulties down
> the road.

I considered to duplicate it, but I opted to reuse it in the end because
I care that the behavior is exactly the same between the two actions
(guix shell --symlink vs guix pack --symlink).  If the way we handle
this is to be changed in the future, I'd want both to be changed at
once, so they remain consistent.  Does this make sense?

>> +++ b/guix/scripts/environment.scm
>> @@ -33,8 +33,10 @@ (define-module (guix scripts environment)
>>    #:use-module ((guix gexp) #:select (lower-object))
>>    #:use-module (guix scripts)
>>    #:use-module (guix scripts build)
>> +  #:use-module ((guix scripts pack) #:select (symlink-spec-option-parser))
>
> You can turn this into #:autoload so we don’t pay the price when not
> using ‘--symlink’.

Done!  Could Guile simply always use lazy loading (autoload by default)?
Otherwise, when is it OK to use autoload and when is it not?

>> +++ b/tests/guix-shell.sh
>> @@ -20,6 +20,8 @@
>>  # Test the 'guix shell' alias.
>>  #
>>
>> +. tests/utils.sh
>> +
>>  guix shell --version
>>
>>  configdir="t-guix-shell-config-$$"
>> @@ -32,6 +34,21 @@ export XDG_CONFIG_HOME
>>
>>  guix shell --bootstrap --pure guile-bootstrap -- guile --version
>>
>> +# '--symlink' can only be used with --container.
>> +! guix shell --bootstrap guile-bootstrap -S /dummy=bin/guile
>> +
>> +if has_container_support; then
>> +    # '--symlink' works.
>> +    echo "TESTING SYMLINK IN CONTAINER"
>> +    guix shell --bootstrap guile-bootstrap --container \
>> +         --symlink=/usr/bin/guile=bin/guile -- \
>> +         /usr/bin/guile --version
>
> This should go to ‘tests/guix-environment-container.sh’, which has all
> the container-related tests.

Done, for the "has_container_support" conditional tests.

Thanks for taking a peek!

Maxim





reply via email to

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