Re: GWL 0.5 fails with plain packages

[Liliana Marie Prikler]

Am Sonntag, dem 31.07.2022 um 17:17 -0400 schrieb Olivier Dion:
> This patch should now have all outputs in _GWL_PROFILE.  There's
> still a problem with the derivation though.
... at the cost of propagating all the additional outputs to processes
that don't need them.

Am Samstag, dem 30.07.2022 um 14:47 -0400 schrieb Olivier Dion:
> I invite you to read this thread
> <https://lists.gnu.org/archive/html/gwl-devel/2022-04/msg00009.html>
> and the one in the following month for all the details.

> Changing all the matching patterns used by GWL to handle new cases
> was deemed too cumbersome.
By whom?

In any case, Guix itself already has a few wrapper types that bundle
packages and outputs.  At the lowest level (as far as I know), there's
<gexp-input>.  Assuming you ignore native?, you can convert a package
and output easily to a <gexp-input> using (gexp-input package output),
and convert it back using the gexp-input-thing and gexp-input-output
accessors.  (Of course, you'd have to restrict your inputs so that only
gexp-inputs whose thing is a package are valid).

On a somewhat higher level there's manifest entries, which you could
create via package->manifest-entry.  Given that GWL is built on top of
manifests it might make sense to allow raw manifest entries and to
transform instances of package+output to manifest entries.

> [T]he short answer is that outputs are not needed by GWL except at a
> single place (gwl/processes.scm:702).
First, I don't think that's true.  Second, if it were, you shouldn't
have that many matching patterns, should you?

Looking at the code around this line, if you were to go with the second
option, you could SRFI-1 partition process-packages into actual
packages and manifest entries, construct one manifest per group and
then merge them.  Alternatively, process packages could already be
lowered to manifests at process construction time, which would also
work for `guix workflow graph'.

Cheers