guix-patches
[Top][All Lists]
Advanced

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

[bug#73833] [PATCH v2 1/5] guix: import: utils: Add function git->origin


From: Nicolas Graves
Subject: [bug#73833] [PATCH v2 1/5] guix: import: utils: Add function git->origin.
Date: Wed, 06 Nov 2024 18:18:16 +0100

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 via email to

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