Re: All updaters are broken

[Ricardo Wurmus <rekado@elephly.net>]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> I managed working on this this evening already.

Thank you for taking the time!

> Am 31.12.22 um 15:27 schrieb Ricardo Wurmus:
>> Commit 8aeccc6240ec45f0bc7bed655e0c8149ae4253eb seems like the problem
>> here.  Hartmut, can you please fix this?  Otherwise I’d like to revert
>> this and related commits ASAP.
>
> I fixed he tests and pushed as d7a9d72bb02a2a3b1a99183655bf878547116032.
>
> Regarding the command "guix refresh": According to my tests only
> invocations not providing a package name failed (see below). Anyhow I
> did not manage fixing this:
>
> options->update-specs need to return update-specs in all cases, and
> currently returns packages if no packages have been named on the
> command line.

It also returns packages when a manifest is provided, or when an
expression is evaluated.  All the internal procedures also assume that
we’re dealing with packages here.  The only special case is in
“args-packages” where “update-specification->update-spec” is used.

We’ll either have to wrap all package values in (update-spec pkg #false)
only to unpack that moments later to get at the wrapped package value or
dispatch on the return type of options->update-specs (possibly after
renaming it to make clear that this returns <package> or <update-spec>
values), treating <update-spec> values differently from <package>
values.

It’s a bit messy because options->update-specs is poorly typed now.  We
could also have it return a compound value (or a union type) with a list
of <update-spec> values and a list of <package> values, and process the
components separately.

-- 
Ricardo