GNU bug report logs - #73073
[PATCH 0/6] Allow origin with label as inputs.

Previous Next

Full log

Message #32 received at 73073 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, 73073 <at> debbugs.gnu.org
Cc: Vivien Kraus <vivien <at> planete-kraus.eu>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#73073] [PATCH 4/6] gnu: gnome-recipes: Move libgd origin
 from phases to native-inputs.
Date: Fri, 06 Sep 2024 22:14:02 +0200

Am Freitag, dem 06.09.2024 um 20:11 +0200 schrieb Simon Tournier:
> Hi Liliana,
> 
> My aim is not to mix, under ’inputs’ record field, the old style
> (label) with the new style (no label) but to have the ’origin’ inside
> ’inputs’ and not inside ’arguments’.
Sure, but you do introduce a label to make that work is what I'm
saying.

> As I wrote in the cover letter:
> 
>         This is annoying because these origins are hidden from
>         ’package-direct-sources’; see module (guix packages).
> 
> So it helps the package. ;-)
> 
> Please note that the docstring of ’package-direct-sources’ is
> currently lying. ;-)  Well, the situation is a bug, IMHO.
I think we should fix ‘package-direct-sources’ then.  The derivation
obviously knows about this input, otherwise the package wouldn't be
built, so the information is there.  I'd also hazard a guess that Rust
being Rust, no useful information for Rust packages comes with package-
direct-inputs if arguments aren't being handled.

> --8<---------------cut here---------------start------------->8---
>   "Return all source origins associated with PACKAGE; including
> origins in PACKAGE's inputs and patches."
> --8<---------------cut here---------------end--------------->8---
> 
> 
> > IMHO, G-Expressions in phases serve in part to facilitate uses like
> > this.
> 
> I agree that G-exps facilitate manipulation of store paths.  But
> using ’origin’ inside arguments appears to me as an abuse of the
> feature.  As I wrote in the cover letter:
> 
>         Moreover and tangentially, it appears to me an anti-pattern
> of the
>         functional paradigm: The data from the impure outside should
> be handled
>         by the ’source’ record field, or otherwise by ’inputs’,
> ’native-inputs’
>         or ’propagated-inputs’ record fields; let say only ’inputs’
> for
>         simplicity.
> 
> Therefore, I strongly think ’origin’ should not be inside arguments.
We could handle it in source at the cost of similar anti-patterns, or
in inputs at the cost of the anti-pattern you suggest.  The Right
Thing™ would be to unbundle these dependencies correctly.

Also note that your argument would apply to #$this-package-input just
as well: it still is magic that pulls in data from the impure outside
world, and you can trivially trick it into doing silly things.  (Just
add inheritance.)

> Somehow, my submission is a proposal for dealing with the case.  And
> it’s not really if it needs to, or should, be done. :-)
You are working on the implicit assumption that everyone agrees that it
needs to be done, then.  

> >               Particularly, we're now even adding a labeled input,
> > which makes for a cursed situation where all but one inputs are
> > unlabeled¹.
> 
> Please note it’s a specific inputs: it’s an ’origin’.  This can be
> checked by the pattern matching, e.g.,
> 
>     (((? string? label) (? origin? o) ;Allow old style as sometimes
> requires by origin in inputs
>      `(,label ,o))
> 
> Other said, it would not be a “cursed situation”; only a situation
> using a locally defined input.
It *is* a cursed situation for the person reading the inputs field. 
Apart from proper unbundling, some other workarounds would be:
- hacking around search-input-file
- making dummy data packages
- named origins (this one requires similar support code to be written
  and has already been rejected once IIRC)
- computed origins
And yes, I label them as workarounds, since they don't address the root
cause of why origins are introduced in arguments.

Sometimes, practicality beats purity: Consider the ungoogled-chromium
recipe if you hadn't had a good scare today.  The fact that this
pattern shows up as rarely as it does is a testament to how well Guix
functions otherwise – but there might still be a need for it in some
fringe circumstances.  I'd rather we don't change code unless the
result is clearly better™, and I don't see that here.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.