In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats:
> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!
I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Still working on that one ...
I'm not sure how much Guix internals have diverged since they forked Nix, but if the dependency analysis of store paths can be done the same way then this should also be straightforward to port to Guix.
With https://github.com/nlewo/nix2container, I'm trying to make a more standalone tool. Basically, a Go binary takes a reference graph and produces a JSON file describing a container image. This JSON file is then ingested by a Skopeo fork (it adds a new `transport`) to produce images (to file, registries,...).
Currently, it supports the dockerTools layering algorithm and is designed to work with Guix [1] as well;)
Ah, I've actually seen this before. Since it's written in Go, you might be able to pretty much copy&paste the Nixery layering strategy into it. I wouldn't mind!
You're saying "it's not a fork, it just uses an earlier, modified version of the codebase". What is a fork if not that?
I don't know how divergent it is, probably quite a lot at this point. The concepts should still be very close though and that should mean that a lot of tooling is theoretically portable between the two.
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!