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

[Steven Allen <steven@stebalien.com>]

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

Ludovic,

On 01-23-16, Ludovic Courtès wrote:
> At the end of a build, guix-daemon scans all the produced file in search
> of references to other store items.  It then records those run-time
> references (so a subset of the build-time dependencies) in the
> /var/guix/db/db.sqlite database, which can be queried with
> ‘guix gc --references’.

So Guix does auto detect which inputs are needed at runtime! Back to my
original question: why? I've read the relevant parts of the thesis (2.1,
3.3, 7.1.5) and none of them actually answer this question. The thesis
answers "why is this not a horrible idea?" with "it appears to work in
practice" (2.1, 7.1.5) which:

1. Isn't very satisfying.
2. Is wrong. It works in practice until some unexpected case comes up
   (e.g. python eggs) and the package manager itself has to be changed.
3. Doesn't actually motivate this feature.

The only motivation I can think of is that it makes packaging (1) easier
(2) less error prone. You don't have to care about what inputs are
needed at runtime, you just have to write down all inputs and the
package manager will detect which ones are needed at runtime for you.
However, this Guix can't fully take advantage of this because it needs
to support cross compilation. Therefore, all *platform-dependent* inputs
needed at build time need to be specially designated.

My proposal is to:

1. Keep everything in the inputs list at runtime (write this list down
   somewhere).
2. Move all build-only inputs into native-inputs.
3. Turn this auto detection into a lint that validates the inputs list
   (verify that the inputs list isn't *missing* an input).
4. Optionally rename native-inputs to build-inputs.

Motivation:

1. One can tell which inputs will be kept at runtime and which will not
   by looking at the package definition.
2. One can package any program without ever having to modify the build
   system or play games (e.g. decompress random files).
3. It's less error prone because it's explicit. Unlike the current
   system, it won't break if some file happens to be compressed or
   encoded in some unexpected format.

And my question is: are there any use cases that this doesn't support?

Sorry for the wall of text and thanks for the thesis/explanation!

-- 
Steven Allen
((Do Not Email <honeypot@stebalien.com>))

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