[bug#73137] this-package-input vs. propagated-inputs in package definition

[Simon Tournier]

Hi,

On lun., 16 sept. 2024 at 13:51, Andy Tai <atai@atai.org> wrote:
> OK I don't know if this is "implementation detail" or a bug, or is as
> intended, that
>
>>considering the current implementation, you cannot reach the 
>>propagated-inputs of the inputs using this-package-inputs.
>
> (seems like a bug to me)

I do not the see the bug. :-) Somehow ’propagated-inputs’ is a run-time
concept, when ’this-package-input’ is a build-time concept.

Roughly, building a package, seen as a functional view, you have to
explicitly list all the inputs of the function.  And there is no hidden
input implicitly attached to one of these inputs.

Somehow, from the point of the package, we list its dependencies and the
package “sees” these dependencies.


> Also, would the same package be in the input list and the
> propagated-input list be a problem?

Reading the entry for ’propagated inputs’ in the Manual:

     Sometimes packages have “propagated inputs”: these are dependencies
     that automatically get installed along with the required package
     (*note ‘propagated-inputs’ in ‘package’ objects:
     package-propagated-inputs, for information about propagated inputs
     in package definitions).

     An example is the GNU MPC library: its C header files refer to
     those of the GNU MPFR library, which in turn refer to those of the
     GMP library.  Thus, when installing MPC, the MPFR and GMP libraries
     also get installed in the profile; removing MPC also removes MPFR
     and GMP—unless they had also been explicitly installed by the user.

     https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-package

and following the suggested link:

          Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
          specified packages will be automatically installed to profiles
          (*note the role of profiles in Guix: Features.) alongside the
          package they belong to (*note ‘guix package’:
          package-cmd-propagated-inputs, for information on how ‘guix
          package’ deals with propagated inputs).

          For example this is necessary when packaging a C/C++ library
          that needs headers of another library to compile, or when a
          pkg-config file refers to another one via its ‘Requires’
          field.

          Another example where ‘propagated-inputs’ is useful is for
          languages that lack a facility to record the run-time search
          path akin to the ‘RUNPATH’ of ELF files; this includes Guile,
          Python, Perl, and more.  When packaging libraries written in
          those languages, ensure they can find library code they depend
          on at run time by listing run-time dependencies in
          ‘propagated-inputs’ rather than ‘inputs’.

          https://guix.gnu.org/manual/devel/en/guix.html#package-Reference


In other words, you put the package dependency under ’inputs’ and if the
internal machinery is unable to correctly set the search path, then you
have to manually move the dependency from ’inputs’ to
’propagated-inputs’.  If freefont is required run-time by the package
’ddd’ and if the machinery is unable to record search patch, then yes
freefont should be listed under propagated-inputs of ’ddd’. 

Maybe I am missing something.

HTH,
simon