Hi Ludo, Ludovic Courtès <[email protected]> writes:
> 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. 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
