this-package-input vs. propagated-inputs in package definition

this-package-input vs. propagated-inputs in package definition

[Andy Tai]

A question on package definition (likely scope of guix-devel, but
anyway posted here first):

I have updated the definition of package ddd which has libxft as
input. Libxft in turn has freefont as propagated-input.   In the
definition of ddd I tried to do

(this-package-input "freefont")

which returns #f.

I had to add freefont as input to ddd to make this work.

As propagated-input should be propagated, shall the addition of
freefont as input to ddd be unneeded?

Re: this-package-input vs. propagated-inputs in package definition

[Simon Tournier]

Hi,

On Mon, 09 Sep 2024 at 11:27, Andy Tai <atai@atai.org> wrote:

> I have updated the definition of package ddd which has libxft as
> input. Libxft in turn has freefont as propagated-input.

What do you mean by ’freefont’?  libxft reads:

    (propagated-inputs
     ;; xft.pc refers to all these.
     (list libxrender
           freetype
           fontconfig))


Cheers,
simon

Re: this-package-input vs. propagated-inputs in package definition

[Andy Tai]

Sorry I meant freetype

On Tue, Sep 10, 2024 at 1:34 AM Simon Tournier <zimon.toutoune@gmail.com> wrote:
>
> Hi,
>
> On Mon, 09 Sep 2024 at 11:27, Andy Tai <atai@atai.org> wrote:
>
> > I have updated the definition of package ddd which has libxft as
> > input. Libxft in turn has freefont as propagated-input.
>
> What do you mean by ’freefont’?  libxft reads:
>
>     (propagated-inputs
>      ;; xft.pc refers to all these.
>      (list libxrender
>            freetype
>            fontconfig))
>
>
> Cheers,
> simon

Re: this-package-input vs. propagated-inputs in package definition

[Simon Tournier]

Hi,

On Mon, 09 Sep 2024 at 11:27, Andy Tai <atai@atai.org> wrote:
> A question on package definition (likely scope of guix-devel, but
> anyway posted here first):
>
> I have updated the definition of package ddd which has libxft as
> input. Libxft in turn has freefont as propagated-input.   In the
> definition of ddd I tried to do
>
> (this-package-input "freefont")
>
> which returns #f.

I think that’s expected.  ’this-package-input’ searches only in the list
of ’inputs’ and ’propagated-inputs’ of the package itself and not of the
inputs.  Somehow, it’s not recursive and “freetype” is not an “inputs”
of the package ddd.

BTW, I am not sure to understand what mean a propagated-inputs in the
context of a build.  I mean, it sounds at run-time, not build-time.  No?
Do I miss something?

> I had to add freefont as input to ddd to make this work.

BTW, for the package ddd, is freetype an input or also a
propagated-input ?


> As propagated-input should be propagated, shall the addition of
> freefont as input to ddd be unneeded?

Well, for sure, considering the current implementation, you cannot reach
the propagated-inputs of the inputs using this-package-inputs.


Cheers,
simon

Re: this-package-input vs. propagated-inputs in package definition

[Andy Tai]

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)

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

On Fri, Sep 13, 2024 at 7:24 AM Simon Tournier <zimon.toutoune@gmail.com> wrote:
> > I had to add freefont as input to ddd to make this work.
>
> BTW, for the package ddd, is freetype an input or also a
> propagated-input ?

Re: 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