[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json
From: |
Maxim Cournoyer |
Subject: |
Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json |
Date: |
Sun, 30 Apr 2023 20:39:48 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Simon,
Simon Tournier <zimon.toutoune@gmail.com> writes:
> Hi Ludo, Maxim, all,
>
> On mar., 25 avril 2023 at 14:40, Ludovic Courtès <ludovic.courtes@inria.fr>
> wrote:
>
>>> Somehow, it reveals 3 currently uncovered cases: computed-file appearing
>>> as,
>>>
>>> 1. ’origin’ in source field (ruby-sorbet-runtime)
>>> 2. ’inputs’ (racket-minimal)
>>> 3. ’snippet’ in origin in source field (chromium)
>>
>> I think #1 and #2 are okay: we can use any file-like object there, not
>> just origin/package. Of course, <origin> is meant to be the best choice
>> for ‘source’, and <package> the best choice for ‘inputs’. But I think
>> it’s fine to occasionally resort to some other abstraction when these
>> two are not adequate.
>
> I agree that any file-like object is nice. Somehow, the issue is to
> “unpack“ the information of this object. For instance,
>
> scheme@(guix-user)> (define ruby-sorbet-runtime (@@ (gnu packages ruby)
> ruby-sorbet-runtime))
> scheme@(guix-user)> (package-source ruby-sorbet-runtime)
> $1 = #<<computed-file> name:
> "ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp:
> #<gexp (begin (use-modules (guix build utils)) (copy-recursively
> (string-append #<gexp-input #<origin #<<git-reference> url:
> "https://github.com/sorbet/sorbet" commit:
> "0.5.10610.20230106174520-1fa668010" recursive?: #f> #<content-hash
> sha256:0f21dl06alxwn6xgdxyrkd58plmmsv04z2bcls9ld4cfzsrs5537> ()
> 7fd7ad6b81e0>:out> "/gems/sorbet-" #<gexp-input "runtime":out>) #<gexp-output
> out>)) gnu/packages/ruby.scm:14071:5 7fd7ae734480> guile: #f options:
> (#:local-build? #t)>
>
>
> and as far as I understand, this case cannot be handled by some generic
> code. The extraction of the “real” origin needs manual and specific
> extraction because of this ’computed-file’.
>
> For sure, ’source’ can use any file-like object because some use-cases
> require that. However, I would be tempted to use an ’origin’ as a
> preferred choice – i.e., when it’s possible and try to make it
> possible. ;-) Because, somehow, it “normalizes“ the source information
> and eases its extraction.
I'm not sure I follow, perhaps because I lack context about how
Disarchiver use the source field of a package. Would you mind
explaining a bit what the problem is or pointing me to a place it was
already explained?
--
Thanks,
Maxim