Re: search-input-file vs (assoc-ref inputs)

Re: search-input-file vs (assoc-ref inputs)

[Zhu Zihao]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Some of my concern about label-less style inputs.

1. How can we refer to a non-package input? Some code might use
something like

(inputs
  `(("xxxx.patch" ,(origin ....))))

If I want to replace this patch, I can simply use list operations from
SRFI-1 to manipulate it. But in label-less style, there's no label for a
<origin> object. Packagers may try to embed these objects into the build
expression using `ungexp`. But I think it violates the dependency
inversion principle(We don't rely on label, but rely on concrete
object).

2. libgcc, libgcc is a specific output of gcc. IIUC in build expression,
it shares label with gcc, gcc is an implicit input in many build
system. It's not so convenience for me to refer libgcc.

For example, I want to set up the `LD_LIBRARY_PATH` for testing. it's
better to use `(string-append (this-package-inputs "libgcc") "/lib")`.
But I can't do this, the label of libgcc is "hidden".
`search-input-directory` doesn't work here because "/lib" is a common
directory exists in many package. I have to write `(dirname
(search-input-file input "libstdc++.so.6"))`, so ugly...

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: search-input-file vs (assoc-ref inputs)

[Ludovic Courtès]

Hi,

Zhu Zihao <all_but_last@163.com> skribis:

> Some of my concern about label-less style inputs.
>
> 1. How can we refer to a non-package input? Some code might use
> something like
>
> (inputs
>   `(("xxxx.patch" ,(origin ....))))

You can either keep labels or, what I would recommend, use gexps and
‘local-file’.  An example of that is commit
a21590dabfcef0aa008503ea981364b90750b07c.

> If I want to replace this patch, I can simply use list operations from
> SRFI-1 to manipulate it. But in label-less style, there's no label for a
> <origin> object. Packagers may try to embed these objects into the build
> expression using `ungexp`. But I think it violates the dependency
> inversion principle(We don't rely on label, but rely on concrete
> object).

That’s true.  OTOH, I think one rarely wants to override a patch because
the patch is usually closely tied to the ‘source’ origin anyway.

But yeah, if you have a concrete example, we could see how well that
works there.

> 2. libgcc, libgcc is a specific output of gcc. IIUC in build expression,
> it shares label with gcc, gcc is an implicit input in many build
> system. It's not so convenience for me to refer libgcc.
>
> For example, I want to set up the `LD_LIBRARY_PATH` for testing. it's
> better to use `(string-append (this-package-inputs "libgcc") "/lib")`.
> But I can't do this, the label of libgcc is "hidden".
> `search-input-directory` doesn't work here because "/lib" is a common
> directory exists in many package. I have to write `(dirname
> (search-input-file input "libstdc++.so.6"))`, so ugly...

I’d do (dirname (search-input-file input "/lib/libstdc++.so.6")).
That’s not pretty, but I wouldn’t call it “ugly” either.  :-)

Before that, you would refer to a label that doesn’t actually appear in
the package’s input (because GCC is an implicit input), which wasn’t
better IMO.

As I wrote back in <https://issues.guix.gnu.org/49169>, there are idioms
we used before and that don’t have an obvious or pleasant translation in
the label-less style.  I think we should look together at those concrete
examples when we find them and see what we can come up with.

Thanks for your feedback!

Ludo’.

search-input-file vs (assoc-ref inputs)

[Leo Famulari]

I noticed that, as part of the transition to the new inputs style [0],
we are sometimes replacing code like (assoc-ref inputs "foo") with
(search-input-file inputs "/bin/foo").

I think that we should instead replace the old style with gexps that
specify which package, in order to keep the equivalent functionality.

Otherwise, we risk regressions, when the code finds a match for the
desired filename in the wrong input.

I would say that (search-input-file) is a replacement for the Guile
(which) procedure.

On the other hand, we can replace (assoc-ref inputs ...) with
(this-package-input "foo").

What do you think?

[0] https://guix.gnu.org/en/blog/2021/the-big-change/

Re: search-input-file vs (assoc-ref inputs)

[Ludovic Courtès]

Hi!

Leo Famulari <leo@famulari.name> skribis:

> I noticed that, as part of the transition to the new inputs style [0],
> we are sometimes replacing code like (assoc-ref inputs "foo") with
> (search-input-file inputs "/bin/foo").
>
> I think that we should instead replace the old style with gexps that
> specify which package, in order to keep the equivalent functionality.
>
> Otherwise, we risk regressions, when the code finds a match for the
> desired filename in the wrong input.
>
> I would say that (search-input-file) is a replacement for the Guile
> (which) procedure.
>
> On the other hand, we can replace (assoc-ref inputs ...) with
> (this-package-input "foo").
>
> What do you think?

It depends.  In cases where we want a specific file or directory, I
think we should use ‘which’, ‘search-input-file’, and
‘search-input-directory’.

Sometimes though we want to form strings such as:

  --with-gmp-prefix=/gnu/store/…-gmp-6.3.0

In that case, (this-package-input "gmp") is more appropriate.

However, there are cases where we want code to be independent from the
package name.

For example, we have two implementations of the MPI standard (openmpi
and mpich) which are mostly interchangeable, for instance via
‘--with-input=openmpi=mpich’.  If we hardcode things like
(this-package-input "openmpi") everywhere, then we effectively prevent
input substitution.  The same goes for cases where we have a “-minimal”
variant: the actual name of the package shouldn’t matter.

To summarize, we should rely on package names only when it is strictly
needed.

Thoughts?

Ludo’.