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,

--8<---------------cut here---------------start------------->8---
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)>
--8<---------------cut here---------------end--------------->8---

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.


On mar., 25 avril 2023 at 09:52, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> This pattern appears to me wrong.  It should use ’snippet’.  And if the
>> point is to have a meaningful path in /gnu/store, as it is the case with
>> icecat or linux or emacs-company-box, the current way is
>> ’computed-origin-method’ from (guix packages).
>>
>> For ’ruby-sorbet-runtime’, the fix seems ’computed-origin-method’.
>
> Per the source, IIRC, 'computed-origin-method' is also considered a hack
> or workaround around the fact that a snippet can't affect the name of a
> source.  But it's a well established one.  That was indeed the rationale
> here (to have meaningful top level directory names matching the source),
> which is worth it in my opinion.

I agree that ’computed-origin-method’ had been considered as a hack.  I
guess, mainly because at the time, the need seemed singular and that
’snippet’ were maybe less powerful.  For what my opinion is worth,
instead of,

--8<---------------cut here---------------start------------->8---
(define (make-sorbet-gem-source gem)
  "Return the source of GEM, a sub-directory."
  (computed-file
   (string-append "ruby-sorbet-" gem "-" sorbet-version "-checkout")
   (with-imported-modules (source-module-closure '((guix build utils)))
     #~(begin
         (use-modules (guix build utils))
         (copy-recursively (string-append #$sorbet-monorepo
                                          "/gems/sorbet-" #$gem)
                           #$output)))))

(define-public ruby-sorbet-runtime
[...]
    (source (make-sorbet-gem-source "runtime"))
--8<---------------cut here---------------end--------------->8---

I would try to “normalize” this behaviour.  Well, it’s not clear for me
if ’computed-origin-method’ is suitable as a basis for that; somehow it
would appear to me the direction for these kind of use cases.

Anyway, from my point of view, considering this very specific use-case
of ruby-sorbet-runtime, the pattern using ’computed-file’ as ’source’ –
only for having the correct store pathname – is not something that I
would introduce when it is avoidable.

And, maybe I am missing a point, but it appears to me avoidable:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build ruby-sorbet-runtime -S
/gnu/store/ni5mz1j7lbdrdqsvdm5dq1d2ack8c8q6-ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout

$ guix hash -r $(guix build ruby-sorbet-runtime -S) $(./pre-inst-env guix build ruby-sorbet-runtime -S)
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
--8<---------------cut here---------------end--------------->8---

using a ’snippet’ – see below.  Basically, ’file-name’ does the job for
the correct name and the other part is just moving content around.
Well, I guess this snippet could be simplified.