Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Simon Tournier <zimon.toutoune@gmail.com> writes:
>
> [...]
>
>>> 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.
>
> Oh, got it.
>
>> 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?
>
> The problem with the idiom used for ‘ruby-sorbet-runtime’ is that the
> origin is hidden inside a gexp.
>
> Thus, the machinery that produces <https://guix.gnu.org/sources.json>
> (the file that SWH fetches periodically to ingest the source code
> packages refer to) will not add it.  To put it differently, we have no
> guarantee that the commit above will be archived and that we’ll
> eventually be able to rebuild ‘ruby-sorbet-runtime’.
>
> So I guess as a matter of policy, we should try and find other ways to
> express this so we don’t lose track of origins.

Thanks for explaining, it makes sense.  One way to tip package writers
in the right direction would be to add a warning when such a situation
occurs upon running 'guix lint'.

> In this particular case, we could do what Simon proposed or, even
> simpler, just add a phase that calls ‘chdir’ (the advantage being that
> we don’t have to create copies of subsets of ‘sorbet-monorepo’).

I seem to recall there was more to it than simply having a
self-contained source correctly named, such as avoiding extra phases
doing chdir and having to delete extraneous .gems that'd get picked up
erroneously and build the wrong thing/fail the build.

Simon's solution is a bit more complicated/verbose than the gexp version
currently in used taste, but it works while preserving the origin and
avoids extra steps in each package that will be using sorbet-monorepo,
so I think I'd go with it.

-- 
Thanks,
Maxim