[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] packages: Support for full Guix specification
From: |
Olivier Dion |
Subject: |
Re: [PATCH v2 1/2] packages: Support for full Guix specification |
Date: |
Tue, 26 Apr 2022 14:59:07 -0400 |
On Tue, 26 Apr 2022, Ricardo Wurmus <rekado@elephly.net> wrote:
> Hi Olivier,
>
> thank for the patch!
>
>> -(define (lookup-package specification)
>> +(define (%lookup-package name+version output)
>> + (list (match (apply lookup-inferior-packages
>> + (cons (current-guix) (string-split name+version #\@)))
>
> I don’t think we need the cons here. As long as the last argument to
> APPLY is a list everything’s fine.
Oh I didn't knew that! Awesome!
>> + ((first . rest) first)
>> + (_ (raise (condition
>> + (&gwl-package-error
>> + (package-spec (string-append name+version
>> output)))))))
>> + output))
>
> I’d prefer to have this return multiple values instead of a compound
> value.
With (values ...)? That's what (gnu packages) does I think.
> And if it had to be a compound value for some reason I’d prefer
> to use a dedicated data type (a record value) instead of a list.
A record would be a better fit than a list yes.
>> +
>> +(define* (lookup-package specification #:optional (output "out"))
>> (log-event 'guix (G_ "Looking up package `~a'~%") specification)
>> - (match (lookup-inferior-packages (current-guix) specification)
>> - ((first . rest) first)
>> - (_ (raise (condition
>> - (&gwl-package-error
>> - (package-spec specification)))))))
>> + (match (string-split specification #\:)
>> + ((name+version sub-drv) (%lookup-package name+version sub-drv))
>> + ((name+version) (simple-package (%lookup-package name+version
>> output)))))
>
> I’m not sure about forcing SIMPLE-PACKAGE to be used because the return
> value might be an output. The stuff in (guix inferior) also doesn’t
> know about outputs, so I feel that we shouldn’t attempt to include
> syntax for selecting outputs. IIRC we’ll end up with all outputs in the
> environment, so there’s no actual effect of picking a specific output.
> I’d prefer to revisit this once (guix inferior) supports selecting
> outputs. What do you think?
I do think it would be better to wait for (guix inferior) to support
selecting outputs. However, I do need selection of outputs for my use
case right now! Specificaly, I need to have debug symbols of many
packages. The quick hack above does the work for me but I understand
that it would be preferable if (guix inferior) has support for outputs
instead.
For example, try the following:
--8<---------------cut here---------------start------------->8---
process test
packages "coreutils" "make"
# {
ls $_GWL_PROFILE > "result.txt"
}
workflow wf
processes test
--8<---------------cut here---------------end--------------->8---
and you will see that there's no `lib/debug` directory. So not all
outputs are in the profile.
What would you suggest I do in the meantime? I have to publish for
december and I don't think we will see this feature very soon. I can
keep this patch on my side for my use case, but it would be awesome if
we have a none ad-hoc solution by the time of publication :-).
Regards,
old
--
Olivier Dion
oldiob.dev
- Packages specification does not work, Olivier Dion, 2022/04/21
- [PATCH v2 2/2] pre-inst-env.in: Export GUIX_EXTENSIONS_PATH, Olivier Dion, 2022/04/22
- Re: [PATCH v2 2/2] pre-inst-env.in: Export GUIX_EXTENSIONS_PATH, zimoun, 2022/04/29
- [PATCH v3 0/1] Support full package specifications, Olivier Dion, 2022/04/29
- [PATCH v3 1/1] packages: Support for full Guix specification, Olivier Dion, 2022/04/29