all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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.