guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

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