From: Nicolas Graves via Guix-patches via <guix-patches@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 73833@debbugs.gnu.org
Subject: [bug#73833] [PATCH v2 1/5] guix: import: utils: Add function git->origin.
Date: Wed, 06 Nov 2024 18:18:16 +0100 [thread overview]
Message-ID: <87ttck9t7r.fsf@ngraves.fr> (raw)
In-Reply-To: <87zfmcwfy5.fsf@gnu.org>
On 2024-11-06 16:16, Ludovic Courtès wrote:
> Hi,
>
> Nice patch series!
>
> Nicolas Graves <ngraves@ngraves.fr> skribis:
[...]
>> - ;; Use a custom cache to avoid cluttering the default one under
>> - ;; ~/.cache/guix, but choose one under /tmp so that it's persistent across
>> - ;; subsequent "guix import" invocations.
>> - (mkdir-p cache)
>> - (chmod cache #o700)
>> - (let-values (((checkout commit _)
>> - (parameterize ((%repository-cache-directory cache))
>> - (update-cached-checkout url
>
> Looks like this bit and its rationale in (guix import go) gets lost
> here: ‘git->origin’ unconditionally uses ~/.cache, which means that
> ‘guix import go -r …’ would fill that directory.
>
> Could we restore that behavior, probably as an option to
> ‘git->origin’?
Yes, we can. However, IIRC my rationale was that the alternative used in
every other import module was to use the store (and not ~/.cache IIRC,
since it uses latest-repository-commit instead of
update-cached-checkout) as a cache. Since we often import/update to
build after that, it seemed quite natural to let the store handle the
cache instead of managing a custom cache for that.
So yes, we loose a bit of functionality, but I think it's more
maintainable this way, if the original author doesn't disagree too much
on that. WDYT?
[...]
>> + (let* ((version (and (pair? ref) (cdr ref)))
>> + (directory commit
>> + (if version
>> + (with-store store
>> + (latest-repository-commit store repo-url
>> + #:ref (if version ref '())))
>> + (values #f #f)))
>> + (vcommit (match ref->commit
>> + (#t commit)
>> + (#f version)
>> + ((? procedure?) (ref->commit version))
>> + (_ #f))))
>
> Weird semantics for ‘ref->commit’. Could it not always be a
> procedure?
I'll try.
>
--
Best regards,
Nicolas Graves
next prev parent reply other threads:[~2024-11-06 17:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 5:29 [bug#73833] [PATCH] guix: import: composer: Improve composer-fetch Nicolas Graves via Guix-patches via
2024-10-17 22:25 ` [bug#73833] [PATCH v2 0/5] Large improvements to import utils, composer import, and refresh Nicolas Graves via Guix-patches via
2024-10-17 22:25 ` [bug#73833] [PATCH v2 1/5] guix: import: utils: Add function git->origin Nicolas Graves via Guix-patches via
2024-11-06 15:16 ` Ludovic Courtès
2024-11-06 17:18 ` Nicolas Graves via Guix-patches via [this message]
2024-10-17 22:25 ` [bug#73833] [PATCH v2 2/5] tests: go: Add mock-git->origin function Nicolas Graves via Guix-patches via
2024-10-17 22:25 ` [bug#73833] [PATCH v2 3/5] guix: import: composer: Improve importer Nicolas Graves via Guix-patches via
2024-11-06 15:41 ` Ludovic Courtès
2024-10-17 22:26 ` [bug#73833] [PATCH v2 4/5] guix: refresh: Keep the version field of each update specification Nicolas Graves via Guix-patches via
2024-11-06 15:47 ` Ludovic Courtès
2024-10-17 22:26 ` [bug#73833] [PATCH v2 5/5] guix: refresh: Implement basic upstream-source-inputs rich updates Nicolas Graves via Guix-patches via
[not found] ` <87y11w9war.fsf@ngraves.fr>
2024-11-07 8:58 ` [bug#73833] [Nicolas Graves via Guix-patches via] " Nicolas Graves via Guix-patches via
2024-11-07 20:14 ` Nicolas Graves via Guix-patches via
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=87ttck9t7r.fsf@ngraves.fr \
--to=guix-patches@gnu.org \
--cc=73833@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=ngraves@ngraves.fr \
/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.