Why does %build-inputs contain the transitive closure of inputs?!

Why does %build-inputs contain the transitive closure of inputs?!

[Jakub Kądziołka]

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

Consider this package:

(use-modules
  (guix packages)
  (guix build-system trivial)
  (gnu packages version-control))

(define foo
  (package
    (name "foo")
    (version "0")
    (source #f)
    (build-system trivial-build-system)
    (arguments
     `(#:builder
       (begin
         (display %build-inputs)
         #t)))
    (inputs
     `(("libgit2" ,libgit2)))
    (synopsis "")
    (description "")
    (home-page "")
    (license #f)))

When we try building it, it prints:

((libgit2 . /gnu/store/hlcfmg5n29ynf354x7s4s7bkxswrmkq4-libgit2-1.0.1) (zlib . /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11) (pcre2 . /gnu/store/ckpchpflfwhag5qsfk8klvmihwzqg9rp-pcre2-10.35) (openssl . /gnu/store/dkzivzn17qilmqdfpyps62b395wxhshh-openssl-1.1.1f))

Why? I would expect only libgit2 to be present, and not all of its
dependencies. It seems to me that this has only downsides - the entire
transitive closure needs to be present during build, even when the
actually used dependencies don't reference it, and the names of inputs
used by packages are now public API, and changing them can break the
build of any transitively dependent package.

I've traced this back to bag->derivation's use of
bag-transitive-inputs, but unfortunately git blame didn't hold any hints
- it has been this way ever since bag->derivation was first implemented.

Am I missing something, or is this a bug?

Regards,
Jakub Kądziołka

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

Re: Why does %build-inputs contain the transitive closure of inputs?!

[Carlo Zancanaro]

Hi Jakub,

On Sat, Aug 08 2020, Jakub Kądziołka wrote:
> Why? I would expect only libgit2 to be present, and not all of 
> its dependencies. ...

If you take a look at the definition for libgit2 in 
gnu/packages/version-control.scm you'll see that this isn't all 
the dependencies for libgit2, it's only the propagated-inputs. For 
instance, libssh2 and http-parser are both inputs for libgit2, but 
they don't appear in your list because they're not propagated.

> ... It seems to me that this has only downsides - the entire 
> transitive closure needs to be present during build, even when 
> the actually used dependencies don't reference it, and the names 
> of inputs used by packages are now public API, and changing them 
> can break the build of any transitively dependent package.

The way propagated inputs work is that they're installed alongside 
the package, so in some sense they are part of the public API of 
the package. They should be used with care, but as far as I can 
tell everything is working properly here.

Carlo

Re: Why does %build-inputs contain the transitive closure of inputs?!

[Jakub Kądziołka]

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

On Sat, Aug 08, 2020 at 10:26:08AM +1000, Carlo Zancanaro wrote:
> Hi Jakub,
> 
> On Sat, Aug 08 2020, Jakub Kądziołka wrote:
> > Why? I would expect only libgit2 to be present, and not all of its
> > dependencies. ...
> 
> If you take a look at the definition for libgit2 in
> gnu/packages/version-control.scm you'll see that this isn't all the
> dependencies for libgit2, it's only the propagated-inputs. For instance,
> libssh2 and http-parser are both inputs for libgit2, but they don't appear
> in your list because they're not propagated.
> 
> > ... It seems to me that this has only downsides - the entire transitive
> > closure needs to be present during build, even when the actually used
> > dependencies don't reference it, and the names of inputs used by
> > packages are now public API, and changing them can break the build of
> > any transitively dependent package.
> 
> The way propagated inputs work is that they're installed alongside the
> package, so in some sense they are part of the public API of the package.
> They should be used with care, but as far as I can tell everything is
> working properly here.

You're absolutely right. This even explains the original weirdness I
saw. Serves me right for hacking at 1 AM...

Sorry for the noise :/

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