Re: Introducing ‘guix pack’

[Chris Marusich <cmmarusich@gmail.com>]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> I had it on my to-do list and Andy said he’d like to have something like
> that to publish Guile 2.2 binaries: the ‘guix pack’ command below is a
> generalization of the code that builds the Guix binary tarball¹.  It
> creates a bundle of the closure of the given packages, with a profile
> containing all the packages.

Very cool!

> lrwxrwxrwx root/root         0 1970-01-01 01:00 ./gnu/store/ynafk7v924xil993dqbx4mxxnm9ifsi6-profile/bin/guild -> /gnu/store/62hqgi4cac0f70v1ycsvv985fl3l1hzr-guile-next-2.1.7/bin/guild

Why does a relative path ./gnu/store/... point to an absolute path
/gnu/store/...?  I would have thought it would be "relative to
relative", or "absolute to absolute", not "relative to absolute".
Perhaps I'm missing something.

What is the expected method for extracting the tarball?  Can you 'cd' to
any directory and run a command like 'tar -xf the_file', or does the
current working directory have to be '/'?

> I’d like to move support for Docker (currently in ‘guix archive’) to
> this new command because I think it’s more appropriate: ‘guix archive’
> is supposed to be rather low-level so it would not create a profile, for
> instance.

My understanding is that one use case for this command is to make it
easy to deploy software (and the closure of its dependencies) using
Docker, in the case (maybe always? I'm not too familiar with Docker)
where you cannot run Guix inside of the Docker instance.  If you could
run Guix, I imagine you would not need this solution, since you could
just install it via the usual Guix mechanisms (e.g., 'guix package -i
foo').

Another use case seems to be specifically the creation of a tarball
containing Guix to enable a binary installation of it (you mentioned
that was the inspiration for this feature).

What other use cases do you imagine?  Is the intent to make it easy to
deploy software (and the closure of its dependencies) to any place where
you either can't or don't want to install Guix first?

> (define* (self-contained-tarball name profile
>                                  #:key deduplicate?)
>   "Return a self-contained tarball containing a store initialized with the
> closure of PROFILE, a derivation.  The tarball contains /gnu/store, /var/guix,
> and PROFILE is available as /root/.guix-profile."

Why is it necessary to include /var/guix?  I'm thinking about the case
where you're using this to package something other than Guix, e.g., some
other piece of software for deployment in a Docker instance.

>           ;; Note: there is not much to gain here with deduplication and
>           ;; there is the overhead of the '.links' directory, so turn it
>           ;; off.
>           (populate-single-profile-directory %root
>                                              #:profile #$profile
>                                              #:closure "profile"
>                                              #:deduplicate? #f)

When you say "there is not much to gain here," do you mean "it is
unlikely that duplication will occur"?  If so, why is that true?

-- 
Chris

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