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

[Steven Allen <steven@stebalien.com>]

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

All,

I just attended David Thompson's talk about Guix and asked some
questions about the difference between inputs, propagated-inputs, and
native-inputs. I believe I now understand what each does but am unclear
as to why.

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?

P.S. Please CC, I'm not subscribed.

-- 
Steven Allen

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