all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Suhail Singh <suhailsingh247@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: "Maxim Cournoyer" <maxim.cournoyer@gmail.com>,
	"Ludovic Courtès" <ludo@gnu.org>,
	guix-devel@gnu.org
Subject: Re: "guix pack -f docker" does too much work
Date: Sat, 14 Sep 2024 20:42:29 -0400	[thread overview]
Message-ID: <87ed5lpx1m.fsf@gmail.com> (raw)
In-Reply-To: <87o74q3wwh.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 14 Sep 2024 20:36:30 +0200")

Ricardo Wurmus <rekado@elephly.net> writes:

>>>> I think it would be great if "guix pack -f docker" could avoid building
>>>> all these identical layers again and again.  Perhaps it would be
>>>> possible to have a single derivation for each layer?  This way we
>>>> wouldn't have to recreate the same layer archives every time.
>>>
>>> That sounds nice in terms of saving CPU time.  It’s less nice in terms
>>> of disk usage: a single ‘guix pack -f docker’ run would populate the
>>> store with roughly twice the size of the closure.
>>>
>>> I think each solution (single derivation vs. one derivation per layer)
>>> makes a different tradeoff.  I don’t have a strong feeling about which
>>> one is better.
>>
>> In past discussions (such as the implementation of the 'RPM' pack
>> format) we had concluded that a single derivation was preferable.  Large
>> chunks to be sent to offload machines over the network are not very
>> practical, and as Ludovic said, they also require more store space.
>
> Dependent on the situation I can see one approach to be preferrable to
> the other, and in other situations this could very well be reversed.

I agree.

> Can we expose this choice to the command line interface of "guix pack"?

That would be quite helpful, indeed.  Happy to help with this if someone
can point me in the right direction, provided the effort of "pointing me
in the right direction" isn't too great to be impractical.

-- 
Suhail


  reply	other threads:[~2024-09-15  0:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 12:58 "guix pack -f docker" does too much work Ricardo Wurmus
2024-05-30 13:10 ` Michal Atlas
2024-06-17 11:21   ` Ludovic Courtès
2024-06-17 11:57     ` Michal Atlas
2024-06-17 21:24       ` Ludovic Courtès
2024-06-01 13:58 ` Ludovic Courtès
2024-06-01 19:07   ` Ricardo Wurmus
2024-06-03  7:09   ` Andy Wingo
2024-06-04 18:14   ` Simon Tournier
2024-09-14 14:55   ` Maxim Cournoyer
2024-09-14 18:36     ` Ricardo Wurmus
2024-09-15  0:42       ` Suhail Singh [this message]
2024-09-26 16:18       ` Simon Tournier
2024-10-05 14:01         ` Maxim Cournoyer

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ed5lpx1m.fsf@gmail.com \
    --to=suhailsingh247@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=rekado@elephly.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.