Re: (propagated) 'inputs' depends on 'outputs'?

[zimoun <zimon.toutoune@gmail.com>]

On Tue, 16 Jun 2020 at 10:28, Julien Lepiller <julien@lepiller.eu> wrote:

>>If I run "guix install foo:out --no-substitutes" then I potentially
>>build any other "outputs"" of foo, e.g., "doc" i.e., potentially
>>download a lot of TeX stuff, or in the case of Git, all the Subversion
>>stuff.  Right?
>
> Yes, because building foo:out doesn't make sense. You build foo and
> guix is nice enough to understand that's wgat you mean :)

I understand.  I do not know if it does not make sense but I
understand. :-)

Well, in this lockdown period, my bandwith and computing resources were
limited and building e.g. all Subversion (or any heavy doc packages)
when I wanted only small output e.g. Git:out (without the svn support)
appeared to me frustrating.

Now it is clear for me, it is by design.  Thank you for the
explanations.


>>> It would make sense to only propagate for some outputs: suppose at
>>> runtime only foo:bin requires the propagation of bar. Since foo and
>>> bar are already built, it should be possible to restrict the
>>> propagation behaviour to that output. Foo:out would not bring in bar
>>> anymore, reducing the closure size.
>>
>>Yes, it seems making sense to only propagated if the output needs it.
>>Well, if it is not implemented yet maybe it is because it is not really
>>necessary. :-)
>
> That cannot be automated because usually we use propagation when there
> is no direct reference. It wouldn't be useful otherwise.

I am not sure to get the point.  From my understanding, it could be
possible to add information to native-inputs, inputs and
propagated-inputs, e.g.,

      ;; For 'git-svn'.
      ("subversion" ,subversion "svn")
      ("perl-term-readkey" ,perl-term-readkey "svn")

or whatever other mean.  Then it becomes possible to only build e.g.,
git:svn and/or propagate specific inputs depending on the outputs.

In the light of your explanation, it does not make sense for
native-inputs and inputs because Guix is building only one thing
(package object, derivation).  But it could make sense for the
propagated-inputs.  Well, the same way that "outputs" are not automatic
but specified somehow by "arguments".

However, it is not implemented and now after the explanations, I do not
know it is is worth.  Well, it is another way to see package
parameters. :-)


Thank you again for the explanations.


Cheers,
simon