Hello, Maxim Cournoyer <[email protected]> skribis:
> Simon Tournier <[email protected]> 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. 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’). WDYT? Ludo’.
