[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (propagated) 'inputs' depends on 'outputs'?
From: |
zimoun |
Subject: |
Re: (propagated) 'inputs' depends on 'outputs'? |
Date: |
Tue, 16 Jun 2020 17:45:52 +0200 |
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