unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Hilton Chain <hako@ultrarare.space>
Cc: Josselin Poiret <dev@jpoiret.xyz>,
	Simon Tournier <zimon.toutoune@gmail.com>,
	Mathieu Othacehe <othacehe@gnu.org>,
	Tobias Geerinckx-Rice <me@tobias.gr>,
	Ricardo Wurmus <rekado@elephly.net>,
	65062@debbugs.gnu.org, Christopher Baines <guix@cbaines.net>
Subject: [bug#65062] [PATCH core-updates 1/1] packages: Specify output in input label when it's not "out".
Date: Sat, 09 Sep 2023 00:03:53 +0200	[thread overview]
Message-ID: <87msxw1fw6.fsf@gnu.org> (raw)
In-Reply-To: <87msyhumwj.wl-hako@ultrarare.space> (Hilton Chain's message of "Thu, 24 Aug 2023 11:42:04 +0800")

Hi,

Hilton Chain <hako@ultrarare.space> skribis:

>> Hilton Chain <hako@ultrarare.space> skribis:
>>
>> > * guix/packages.scm (add-input-label): Specify output when it's not "out".
>>
>> [...]
>>
>> > +         (list (string-append (package-name package) ":" output)
>> > +               package
>> > +               output)))
>>
>> The Grand Plan¹ is to eventually get rid of labels entirely (or almost:
>> there’d still be input alists on the build side).  As such, I thought we
>> shouldn’t worry too much about what the actual label is.  But perhaps
>> you stumbled upon situations where this is a problem?  Could you
>> describe them?

[...]

> My main concern is that currently modify-inputs, this-package-input
> and this-package-native-input operate on input labels and there would
> be duplicated labels if adding multiple outputs of a package.
>
> For modify-inputs, I think there's no approach to solve this without
> also specifying labels in inputs.

Yes, good point.

Another, more radical approach, would be to change semantics, whereby
(inputs (list p)) would mean that all the outputs of ‘p’, not just
“out”, are taken as inputs.  That’d simplify inputs at the expense of
precision, and (this-package-input NAME) would always be unambiguous.

But maybe that’s too radical and uncertain.

So all things considered, I guess you’re right and we should do what you
propose.

Minor issues:

> --- a/guix/packages.scm
> +++ b/guix/packages.scm
> @@ -626,7 +626,13 @@ (define (add-input-label input)
>      ((? package? package)
>       (list (package-name package) package))
>      (((? package? package) output)                ;XXX: ugly?
> -     (list (package-name package) package output))
> +     (if (string=? output "out")
> +         ;; (package "out") => ("package" package "out")
> +         (list (package-name package) package output)
> +         ;; (package "output") => ("package:output" package "output")
> +         (list (string-append (package-name package) ":" output)
> +               package
> +               output)))

Rather write it as two separate clauses, without comments:

  (((? package? package) "out")
   …)
  (((? package? package) output)
   …)

Could you also add a test case in ‘tests/packages.scm’ that would look
up inputs by those labels?

Thanks,
Ludo’.




  parent reply	other threads:[~2023-09-08 22:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-05  2:50 [bug#65062] [PATCH core-updates 0/1] Specify output in input label when it's not "out" Hilton Chain via Guix-patches via
2023-08-05  2:53 ` [bug#65062] [PATCH core-updates 1/1] packages: " Hilton Chain via Guix-patches via
2023-08-22 16:00   ` Ludovic Courtès
2023-08-24  3:42     ` Hilton Chain via Guix-patches via
2023-08-25 11:10       ` Josselin Poiret via Guix-patches via
2023-09-08 22:03       ` Ludovic Courtès [this message]
2023-10-03  9:13         ` Hilton Chain via Guix-patches via
2023-08-05  3:01 ` [bug#65062] [PATCH core-updates 0/1] " Hilton Chain via Guix-patches via
2023-08-05  3:19   ` Hilton Chain via Guix-patches via
2023-10-03  9:15 ` [bug#65062] [PATCH v2 core-updates 0/2] packages: Lookup inputs by specification Hilton Chain via Guix-patches via
2023-10-03  9:17   ` [bug#65062] [PATCH v2 core-updates 1/2] ui: package-specification->name+version+output: Move to (guix packages) Hilton Chain via Guix-patches via
2023-10-03  9:17   ` [bug#65062] [PATCH v2 core-updates 2/2] packages: Lookup inputs by specification Hilton Chain via Guix-patches via
2023-12-20 21:26     ` [bug#65062] [PATCH core-updates] " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msxw1fw6.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=65062@debbugs.gnu.org \
    --cc=dev@jpoiret.xyz \
    --cc=guix@cbaines.net \
    --cc=hako@ultrarare.space \
    --cc=me@tobias.gr \
    --cc=othacehe@gnu.org \
    --cc=rekado@elephly.net \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).