Subject: [bug#43193] [PATCH] guix: Add --with-dependency-source option

From: Jesse Gibbons <[email-masked]>
Date: Fri, 11 Sep 2020 12:28:31 -0600

On 9/11/20 9:43 AM, Ludovic Courtès wrote:
> Hi,
>
> Jesse Gibbons <[email-masked]> skribis:
>
>>> Could you:
>>>
>>>     1. adjust doc/guix.texi accordingly?  That is, if we rename this new
>>>        option to ‘--with-source’, simply add a note stating that it’s
>>>        recursive.
>> I included this in the attached patch.
>>>     2. add a test to tests/guix-build.sh?  There are already --with-source
>>>        tests in other files.  You can mimic them, essentially to make sure
>>>        the option has an effect.
>>>     3. optionally add an entry as a separate commit to
>>>        etc/news.scm.  I can do that for you if you want.
>>>
>> Do you still think the tests should be updated and this change should
>> be announced in the news file? I'm willing to do these.
> Yes, please.  There’s should be a test that checks that --with-source
> works for non-leaf packages.  A new entry would also be nice.
I will work on that then.
>
>>  From 2786da1e7011c59f08fc150dfa284f35bc0ed093 Mon Sep 17 00:00:00 2001
>> From: Jesse Gibbons <[email-masked]>
>> Date: Thu, 3 Sep 2020 17:45:08 -0600
>> Subject: [PATCH 1/1] guix: Make --with-source option recursive
>>
>> * guix/scripts/build.scm: (transform-package-inputs/source): new
>>    function
>> (evaluate-source-replacement-specs): new function
>> (%transformations): change with-source to use
>> evaluate-source-replacement-specs
>>
>> *doc/guix.texi (Package Transformation Options): Document it.
> Nitpick: There are spacing and capitalization issues.  Please see ‘git
> log’ for examples.
I'll fix this.
>> +++ b/doc/guix.texi
>> @@ -9129,7 +9129,8 @@ without having to type in the definitions of package variants
>>   @itemx --with-source=@var{package}=@var{source}
>>   @itemx --with-source=@var{package}@@@var{version}=@var{source}
>>   Use @var{source} as the source of @var{package}, and @var{version} as
>> -its version number.
>> +its version number.  This replacement is applied recursively on all
>> +dependencies only if PACKAGE is specified.
> s/PACKAGE/@var{package}/
>
> However, the semantics are a bit “weird”.  I would just do the recursive
> replacement thing unconditionally.  WDYT?
>
>> +(define (transform-package-inputs/source replacement-specs)
>> +  "Return a procedure that, when passed a package, replaces its direct
>> +dependencies according to REPLACEMENT-SPECS.  REPLACEMENT-SPECS is a list of
>> +strings like \"guile=/path/to/source\" or
>> +\"guile=https://www.example.com/guile-source.tar.gz\" meaning that, any
>> +dependency on a package called \"guile\" must be replaced with a dependency on a
>> +\"guile\" built with the source at the specified location."
>> +  (match (string-tokenize (car replacement-specs) %not-equal)
>> +    ((spec url)
> s/url/file/ since it’s a file name.
>
>> +     (lambda (store obj)
>> +       (let* ((replacements (evaluate-source-replacement-specs replacement-specs
>> +                                                               (lambda (old url)
>> +                                                                 (package-with-source store old url))))
>> +              (rewrite (package-input-rewriting/spec replacements))
>> +              (rewrite* (lambda (obj)
>> +                          (rewrite obj))))
>> +         (if (package? obj)
>> +             (rewrite* obj)
>> +             obj))))
>> +    ((url)
>> +     (transform-package-source replacement-specs))))
> So maybe drop the second clause for non-recursive replacement, and drop
> ‘transform-package-source’ as well.
I included a fallback to transform-package-source because the following 
happens:

$ ./pre-inst-env guix build --with-source=$(guix build --source hello) hello
guix build: error: invalid source replacement specification: 
"/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz"

This does not fail when I fall back to the non-recursive logic.

I can drop transform-package-source, but I will need to do some more 
hacking to figure out how the package name and version are parsed from 
the file name as described in the manual, and move it to the logic in 
transform-package-inputs/source. I'm not going to have as much free time 
starting next week, so I might not be able to do that for a while, but I 
will try to get it done ASAP.

> Thanks!
> Ludo’.