From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 58812@debbugs.gnu.org
Subject: [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell'.
Date: Thu, 10 Nov 2022 09:49:34 -0500 [thread overview]
Message-ID: <87k042x3sx.fsf@gmail.com> (raw)
In-Reply-To: <87sfiqhp1u.fsf@gnu.org> ("Ludovic Courtès"'s message of "Thu, 10 Nov 2022 15:17:17 +0100")
Hi Ludo!
Ludovic Courtès <ludo@gnu.org> writes:
> Hi Maxim!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> 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':
>
> It’s right below the bit you quoted:
>
> The '@ref' command can tempt writers to express themselves in a
> manner that is suitable for a printed manual but looks awkward in the
> Info format. Bear in mind that your audience could be using both the
> printed and the Info format. For example: […]
Yes, and I don't get it :-)
--8<---------------cut here---------------start------------->8---
The '@ref' command can tempt writers to express themselves in a
manner that is suitable for a printed manual but looks awkward in the
Info format. Bear in mind that your audience could be using both the
printed and the Info format. For example:
Sea surges are described in @ref{Hurricanes}.
looks ok in the printed output:
Sea surges are described in Section 6.7 [Hurricanes], page 72.
but is awkward to read in Info, "note" being a verb:
Sea surges are described in *note Hurricanes::.
--8<---------------cut here---------------end--------------->8---
I don't see a "note" in the final sentence that should make it awkward?
It's lacking a "see " prefix though, which could help to make things a
bit clearer, I guess.
It looks the same in info as in the pxref example given above:
--8<---------------cut here---------------start------------->8---
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---
I'm also unsure where the "see" comes before That:: above. Is it a
mistake in the manual?
>>>> +(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?
>
> They don’t have to be consistent. Use of ‘relative-file-name’ here for
> example is dictated by the needs of relocatable packs. It doesn’t have
> to be this way here.
>
> I think it’s best to keep separate copies here (they likely won’t be
> exactly the same).
OK, I see you point about relative-file-name not being needed. I'll make
the change.
>>>> +++ 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)?
>
> #:select could be synonymous with #:autoload, if that’s what you mean,
> but in general Guile cannot know whether autoloading is semantically
> equivalent to eagerly loading: there might be side-effects happening
> when the top-level of the module runs.
Perhaps there could be a strict execution mode where it is assumed that
side effects are not used when modules run? That seems a seldom used
feature anyway, and could enable making lazy loading of modules the
default.
>> Otherwise, when is it OK to use autoload and when is it not?
>
> #:autoload exists as a way to amortize initialization costs and make
> sure only necessary functionality gets loaded, thereby reducing CPU and
> memory usage.
>
> Only the module user can tell whether #:autoload is appropriate. In
> general you’d use it for optional functionality that has a
> non-negligible memory footprint or that would noticeably degrade startup
> time.
>
> Ludo’.
Thank you for the explanations and review! I'll send a v3 shortly.
--
Maxim
next prev parent reply other threads:[~2022-11-10 14:50 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 3:41 [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell' Maxim Cournoyer
2022-10-27 3:50 ` [bug#58812] [PATCH 1/5] Makefile.am: Sort EXTRA_DIST entries Maxim Cournoyer
2022-10-27 3:50 ` [bug#58812] [PATCH 2/5] tests: Add a tests/utils.sh support file Maxim Cournoyer
2022-11-09 21:07 ` [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell' Ludovic Courtès
2022-11-10 3:38 ` Maxim Cournoyer
2022-11-10 4:23 ` [bug#59164] [PATCH v2 1/4] Makefile.am: Sort EXTRA_DIST entries Maxim Cournoyer
2022-11-10 4:23 ` [bug#59161] [PATCH v2 2/4] install: Validate symlink target in evaluate-populate-directive Maxim Cournoyer
2022-11-10 4:23 ` [bug#59162] [PATCH v2 3/4] guix: shell: Add '--symlink' option Maxim Cournoyer
2022-11-10 4:23 ` [bug#59163] [PATCH v2 4/4] shell: Detect --symlink spec problems early Maxim Cournoyer
2022-10-27 3:50 ` [bug#58812] [PATCH 3/5] install: Validate symlink target in evaluate-populate-directive Maxim Cournoyer
2022-11-09 21:06 ` [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell' Ludovic Courtès
2022-11-10 3:37 ` Maxim Cournoyer
2022-11-17 17:37 ` [bug#59164] Coding style: similarly-named variables Ludovic Courtès
2022-11-17 18:44 ` [bug#58812] " zimoun
2022-11-18 17:02 ` Maxim Cournoyer
2022-11-21 15:02 ` zimoun
2022-11-21 15:52 ` [bug#59164] " zimoun
2022-11-21 20:55 ` Maxim Cournoyer
2022-11-22 14:35 ` [bug#59164] " zimoun
2022-11-25 15:23 ` Guile debugger workgroup? (was: Coding style: similarly-named variables) Maxim Cournoyer
2022-11-26 11:22 ` Guile debugger workgroup? Ludovic Courtès
2022-11-27 3:16 ` Maxim Cournoyer
2022-11-28 10:53 ` Ludovic Courtès
2022-11-28 13:41 ` Attila Lendvai
2022-11-28 14:50 ` Maxim Cournoyer
2022-11-29 8:46 ` Ludovic Courtès
2022-11-30 3:44 ` Attila Lendvai
2022-11-27 12:04 ` zimoun
2022-11-28 0:27 ` Maxim Cournoyer
2022-11-28 11:06 ` Ludovic Courtès
2022-11-28 12:31 ` zimoun
2022-11-27 20:46 ` Attila Lendvai
2022-11-28 0:41 ` David Pirotte
2022-11-28 0:45 ` David Pirotte
2022-11-28 2:06 ` Maxim Cournoyer
2022-11-28 7:22 ` Joshua Branson
2022-11-28 11:09 ` Ludovic Courtès
2022-11-28 14:12 ` Attila Lendvai
2022-11-29 8:54 ` Ludovic Courtès
2022-11-28 12:24 ` Guile debugger workgroup? (was: Coding style: similarly-named variables) Csepp
2022-11-30 7:09 ` Guile debugger workgroup? Jannneke Nieuwenhuizen
2022-11-26 14:47 ` [bug#58812] [bug#59164] Coding style: similarly-named variables Ludovic Courtès
2022-11-17 20:34 ` Maxim Cournoyer
2022-11-20 10:46 ` [bug#58812] " Ludovic Courtès
2022-10-27 3:50 ` [bug#58812] [PATCH 4/5] guix: shell: Add '--symlink' option Maxim Cournoyer
2022-11-09 20:58 ` [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell' Ludovic Courtès
2022-11-10 3:10 ` Maxim Cournoyer
2022-11-10 14:17 ` Ludovic Courtès
2022-11-10 14:49 ` Maxim Cournoyer [this message]
2022-11-10 15:16 ` Maxim Cournoyer
2022-11-14 9:18 ` Ludovic Courtès
2022-11-10 16:05 ` [bug#58812] [PATCH v3 1/4] Makefile.am: Sort EXTRA_DIST entries Maxim Cournoyer
2022-11-10 16:05 ` [bug#58812] [PATCH v3 2/4] install: Validate symlink target in evaluate-populate-directive Maxim Cournoyer
2022-11-10 16:05 ` [bug#58812] [PATCH v3 3/4] guix: shell: Add '--symlink' option Maxim Cournoyer
2022-11-10 16:05 ` [bug#58812] [PATCH v3 4/4] shell: Detect --symlink spec problems early Maxim Cournoyer
2022-11-16 19:03 ` [bug#58812] [PATCH 0/5] Add --symlink option to 'guix shell' zimoun
2022-11-16 19:34 ` Maxim Cournoyer
2022-10-27 3:51 ` [bug#58812] [PATCH 5/5] shell: Detect --symlink spec problems early Maxim Cournoyer
2022-11-15 21:24 ` bug#58812: [PATCH v3 1/4] " Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k042x3sx.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=58812@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.