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

[Ludovic Courtès]

Hello,

Ricardo Wurmus <address@hidden> skribis:

>> Ricardo Wurmus <address@hidden> 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.

I see, that makes sense.

>> 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.

Cool!

>> 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.

OTOH if we return a complete list of inputs, then we don’t have to worry
about the cost of ‘changed-inputs’ since that would only be called on
demand; also there’d be a single call site for ‘changed-inputs’.

Well, you tell us!  :-)

Thanks,
Ludo’.