From: Julien Lepiller <julien@lepiller.eu>
To: zimoun <zimon.toutoune@gmail.com>,guix-devel@gnu.org
Subject: Re: (propagated) 'inputs' depends on 'outputs'?
Date: Tue, 16 Jun 2020 10:28:06 -0400 [thread overview]
Message-ID: <D3D54997-D066-48A7-AB31-3FE3E637694A@lepiller.eu> (raw)
In-Reply-To: <86zh93qj1l.fsf@gmail.com>
Le 16 juin 2020 08:41:58 GMT-04:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Bonjour Julien,
>
>On Sat, 13 Jun 2020 at 07:38, Julien Lepiller <julien@lepiller.eu>
>wrote:
>
>> Exactly, no. You cannot separate inputs from outputs, because they
>are
>> part of the same derivation. When you build an output, you actually
>> build the complete derivation and there's no way to separate that in
>> "this part builds out" and "this part builds doc", etc.
>
>So it means that I need to build all the outputs even if I am
>interested
>in only one, right?
Absolutely, but you shouldn't thenk of it as building multiple outputs, because you are really just building one thing: there is only one package object, one derivation. It happens to create multiple directories in the store, but there's only one thing you build.
>
>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 :)
>
>Even if at the end, only the references used by "foo:out" will be
>tracked and all the others potentially garbage collected. Right?
>
>
>> 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.
>
>
>Thank you for explaining. It is clearer for me now.
>
>Cheers,
>simon
next prev parent reply other threads:[~2020-06-16 14:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 11:01 (propagated) 'inputs' depends on 'outputs'? zimoun
2020-06-13 11:16 ` Christopher Baines
2020-06-16 12:31 ` zimoun
2020-06-16 15:34 ` Ricardo Wurmus
2020-06-16 15:52 ` zimoun
2020-06-13 11:38 ` Julien Lepiller
2020-06-16 12:41 ` zimoun
2020-06-16 14:28 ` Julien Lepiller [this message]
2020-06-16 15:45 ` zimoun
2020-06-19 20:47 ` Ludovic Courtès
2020-06-19 21:44 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D3D54997-D066-48A7-AB31-3FE3E637694A@lepiller.eu \
--to=julien@lepiller.eu \
--cc=guix-devel@gnu.org \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).