On Sat, Jan 06, 2018 at 01:46:18PM +0100, Ricardo Wurmus wrote: > I’m not sure, but it seems wrong. What I used to do is to create a > profile and export that recursively: > > guix archive --export --recursive \ > $(readlink -f /project/.guix-profile) | \ > gzip --stdout - > my-profile.nar.gz > > This should include propagated inputs.
I'll try that again, but it does not appear to be so elegant. Besides an archive is an archive ;). It should be a 'closure'. > > NAR files are signed. I think it would be very useful to be able to > > distribute unsigned NAR files. > > > > Q2: can signing/checking be made optional? > > > > > I can't view the contents. > > > > Q3: how do we view the contents of a NAR file without unpacking it? > > I don’t think you can. It’s a custom format implemented by > nix/libutil/archive.cc. Yes, we ought to do something about that. Nix nar files could be be unpacked before. I'll take a look at that. Not goot to have obscure formats. > > Q4: is there a nice way to include a profile path in the store that > > can be used quickly? > > What do you mean by “include … in the store”? With the above command to > recursively export profiles you get a single archive that can be > imported to the store as a profile. It is elegant (if it works) and not elegant at the same time. I am thinking more of a symlink -S option like we have with pack. > > Q5: is there an elegant way to add those unpacked store items to the > > database? > > What unpacked store items do you mean? I mean how to add the contents of a pack image to the store. What archive does, but then via the pack command. Well, if archive works properly, pack does not need to do anything ;) I know pack serves one purpose - deployment without guix - archive another - deployment with guix. It is that archive is not working so well, right now. pack could be supporting deployment on guix and archive could behave a bit more like pack. I'll take a look at the archive format. Pj.
