Re: Design decision behind inputs/native-inputs/propagated-inputs

[Ludovic Courtès]

Hello,

Steven Allen <address@hidden> skribis:

> I just attended David Thompson's talk about Guix and asked some

Cool, glad that it led you to contact us!  ;-)

> Currently, I use Arch. On Arch, we have makedepends and depends where
> only depends are kept at runtime. On Guix, this distinction is detected
> at build time by searching the output files for references into the
> inputs. However, unless I'm mistaken, native-inputs are *usually* build
> dependencies and inputs are *usually* runtime dependencies. So, my
> question is why not:
>
> 1. Get rid of the automagic run/build dependency detection.
> 2. Have:
>   a. private-inputs -- runtime dependencies not linked into the environment
>   b. propagated-inputs -- no change
>   c. build-inputs -- always native, never included in the final output
>
> Specifically, what is the use case for non-native build-only dependencies 
> (inputs that are not included in the final package) and native runtime
> dependencies (native-inputs that *are* included in the final package)?
> Alternatively, am I completely missing the point?

The description of these three things has been improved in the manual on
‘master’, compared to what’s on the on-line manual:

--8<---------------cut here---------------start------------->8---
     ‘inputs’ (default: ‘'()’)
     ‘native-inputs’ (default: ‘'()’)
     ‘propagated-inputs’ (default: ‘'()’)
          These fields list dependencies of the package.  Each one is a
          list of tuples, where each tuple has a label for the input (a
          string) as its first element, a package, origin, or derivation
          as its second element, and optionally the name of the output
          thereof that should be used, which defaults to ‘"out"’ (*note
          Packages with Multiple Outputs::, for more on package
          outputs).  For example, the list below specifies 3 inputs:

               `(("libffi" ,libffi)
                 ("libunistring" ,libunistring)
                 ("glib:bin" ,glib "bin"))  ;the "bin" output of Glib

          The distinction between ‘native-inputs’ and ‘inputs’ is
          necessary when considering cross-compilation.  When
          cross-compiling, dependencies listed in ‘inputs’ are built for
          the _target_ architecture; conversely, dependencies listed in
          ‘native-inputs’ are built for the architecture of the _build_
          machine.

          ‘native-inputs’ is typically where you would list tools needed
          at build time but not at run time, such as Autoconf, Automake,
          pkg-config, Gettext, or Bison.  ‘guix lint’ can report likely
          mistakes in this area (*note Invoking guix lint::).

          Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
          specified packages will be force-installed 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 a C/C++ library 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 ELF’s ‘RUNPATH’; this includes Guile, Python,
          Perl, GHC, and more.  To ensure that libraries written in
          those languages can find library code they depend on at run
          time, run-time dependencies must be listed in
          ‘propagated-inputs’ rather than ‘inputs’.
--8<---------------cut here---------------end--------------->8---

In short, the distinction between ‘native-inputs’ and ‘inputs’ exists
solely because Guix supports cross-compilation.  Otherwise it would be
unneeded.

Propagated inputs are a way to manually say: “I want this package to
automatically pull in those other packages.”  This is necessary in the
cases given above.

Does this clarify the rationale?

Thanks for your feedback,
Ludo’.