Re: Introducing ‘guix pack’

[ludo@gnu.org (Ludovic Courtès)]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

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

[...]

>> 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 '/'?

The extraction method is supposed to be the same as for the Guix binary
tarball, since it’s exactly the same code:

  https://gnu.org/software/guix/manual/html_node/Binary-Installation.html

>> 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?

The use case for ‘guix archive -f docker’ (which already exists; I’m
just proposing to move it to ‘guix pack’) is when you’d like to pass
software to someone who has Docker but not Guix:

  https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00048.html

I think the impetus for Ricardo was when the Emacs folks were discussing
of building Docker images of Emacs.  :-)

But I guess it’s not uncommon for people to have Docker and not Guix, as
sad as it may sound.  ;-)

>> (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.

FTR, this code was in (gnu system install) until now where it was used
to create the Guix standalone tarball.

For the Guix binary tarball, it’s important to have /var/guix with the
store database properly initialized and so on.

For other cases, it’s probably less useful.  We could make it optional.

>>           ;; 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?

In the Guix binary tarball, there are few files present several times,
hence “not much to be gained.”  Back then I compared both and the
deduplicated version was about the same size as the other one, IIRC.

But again, for the more general case, I agree it would make sense to
have an option for this.

I’ve pushed ‘guix pack’ in commit
239c22663ac928618028c4ec03cefc77de788e9d (slightly improved version of
what I posted.)  Still many ways in which we can improve it!

The Docker backend requires a bit of thought because of the dependency
on libgcrypt and guile-json, which ‘gexp->derivation’ doesn’t yet handle
nicely.

Thanks for your feedback!

Ludo’.