[bug#34040] [PATCH 1/2] refresh: Suggest input changes when updating.

[Ricardo Wurmus <rekado@elephly.net>]

Hi,

sorry for not repyling earlier.  I did not see this message.

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>>    (version        upstream-source-version)        ;string
>>    (urls           upstream-source-urls)           ;list of strings
>>    (signature-urls upstream-source-signature-urls  ;#f | list of strings
>> -                  (default #f)))
>> +                  (default #f))
>> +  (input-changes  upstream-source-input-changes
>> +                  (default '()) (thunked)))
>
> Any particular reason for making ‘input-changes’ thunked?
>
> This causes a failure in tests/upstream.scm (because two evaluator
> procedures are unlikely to be eq?).  I would fix it by removing the
> ‘thunked’ property but I’m not sure if it’d make sense.

Oh, I’m sorry for breaking this.

My thinking was that this field should be lazily evaluated, because it
is somewhat expensive.  “input-changes” gets its value from calling
“changed-inputs” on a newly imported package.  I wanted to avoid the
import when a user is not interested in the “input-changes” field.

> Another thing: “upstream source” designates something
> absolute/stateless, but “input changes” designates something
> relative/stateful.  So on second thought, I wonder whether
> <upstream-source> is the right place for it.
>
> I was thinking that updaters could maybe return two values
> (<upstream-source> + list of changed inputs), which would be equivalent
> but somewhat clearer.  The downside is that we’d have to change all
> updaters to return multiple values.

This sounds like a good idea and I’m fine with changing all of the
importers.

> Alternately, we could change ‘input-changes’ to ‘inputs’, which would be
> absolute, not relative, and thus ‘package-update’ would take care of
> calling ‘changed-inputs’ etc.

That would also work, but I think I prefer an updater to report changes
rather than a new list of inputs.

--
Ricardo