help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Steven Allen
Subject: Re: Design decision behind inputs/native-inputs/propagated-inputs
Date: Thu, 21 Jan 2016 11:08:11 -0500
User-agent: Mutt/1.5.23.1 (2014-03-12)

On 01-21-16, Ludovic Courtès wrote:
> 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?

I believe I understand what they mean and how they solve the problem. My
question is more "why autodetect runtime dependencies"? That is,
dependencies are currently available at runtime as follows:

 Type              | Run Time
 ------------------+----------------------------------------------
 inputs            | autodetect (if referenced)
 propagated-inputs | always (included in the profile)
 native-inputs     | autodetect (if referenced)

However, I can't think of any cases where the following wouldn't suffice:

 Type              | Run Time                         | In Arch
 ------------------+----------------------------------+-----------
 inputs            | always                           | (pseudo-)depends
 propagated-inputs | always (included in the profile) | depends
 native-inputs     | never                            | makedepends

The key difference being the lack of autodetection in the second case.

In words, I can't think of any cases where one *would* want
native-inputs at runtime and/or *not* want (non-native) inputs at
runtime.

I ask because I hate automagic (magical autodetection). To illustrate,
given:

    (package
        (name "foo")
        (inputs `(("bar", bar)))
        (native-inputs `(("baz", baz)))
        ...
    )

I know that the default output of bar, will be available at build time
but whether or not it remains available at runtime depends on whether or
not my package includes the string `/gnu/store/$hash-bar/...` somewhere
in its output. Why not just say "bar will be available at runtime and
baz will not" (really "baz may not" because it might be an input to
another package).

-- 
Steven Allen

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]