Re: guix pack file enumerator?

[Ricardo Wurmus <rekado@elephly.net>]

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

> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> “guix pack” is great for deployment of applications to servers that
>> don’t have Guix.  For a project I have a “deploy” target in my Makefile
>> that essentially does this:
>>
>>     cat $(shell guix pack -RR -e '(load "guix.scm")' -S /bin=bin) | ssh remote-server "tar xvzf - -C /where/i/want/it"
>>
>> This is fine for small deployments, but it’s a little annoying that it
>> transfer *all* the files, even those that haven’t changed.  So I thought
>> I could use rsync here, but it’s inconvenient that “guix pack” will do
>> what it was designed for and produce a single file bundle.
>>
>> What do you think about adding an output format that is no format at all
>> but a file enumeration printed to stdout?  That way I could use “guix
>> pack” to produce a list of files to transfer and use that to transfer
>> only the unchanged files.  Alternatively, perhaps we could have a
>> “directory” format that merely copies (or links) the files to a new
>> directory root.
>
> You could untar the pack and rsync it.  We could have a ‘directory’
> format but I’m afraid it would duplicate too much of the tarball code
> (we’d have to check).

I’m unpacking to rsync now, but it’s not great to duplicate files on the
local disk only to send them over the network.  The ideal workflow for
me would treat the store on my local machine as the source and the
remote machine as the target, without any copying from source to source
in between.

The local-unpack method also requires an empty directory to be
maintained; it needs to be emptied before the next time we try to unpack
anything.

Another downside is the creation of the tarball itself.  I don’t need it
but it’s still created only to be destroyed in the next step.  This is
unfortunate, because Guix could use a different mechanism to “check out”
files from the store to a new location.

> When you think about it, you could just as well have Guix on the other
> side and then use ‘guix copy’… or maybe use Guix directly there.  (As in
> ‘guix pack --localstatedir -RR guix’.)

I didn’t consider this, but yes: this is an option.  It requires the
target to be actively involved, though, which means that I need to spend
more time preparing it.  There’s a certain appeal in treating the target
as a mere dumping ground and coordinating everything from my development
machine.

> I know it’s not what you had in mind, but it seems to me that there’s a
> continuum here, and maybe there’s just a gap to bridge to allow for
> smoother workflows?

Probably.  The only difficulty I see is that none of the formats that
“guix pack” supports allow for arbitrary variations in the packing
process, such as using a different tool for the packing.  To be fair:
none of the currently supported formats need this level of flexibility.
But extending “guix pack” to domains that it was not primarily designed
to cover (such as deploying a pack before it is produced as a local
artifact) may require some of that flexibility.

-- 
Ricardo