guix describe command shows precisely which commits were used
to build the instance of Guix we’re using (veja Invocando
We can replicate this instance on another machine or at a different point in
time by providing a channel specification “pinned” to these commits that
looks like this:
;; Deploy specific commits of my channels of interest. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "6298c3ffd9654d3231a6f25390b056483e8f407c")) (channel (name 'variant-packages) (url "https://example.org/variant-packages.git") (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))
To obtain this pinned channel specification, the easiest way is to run
guix describe and to save its output in the
in a file, like so:
guix describe -f channels > channels.scm
guix time-machine -C channels.scm -- shell python -- python3
Given the channels.scm file, the command above will always fetch the
exact same Guix instance, then use that instance to run the exact
same Python (veja Invoking
guix shell). On any machine, at any time, it
ends up running the exact same binaries, bit for bit.
Pinned channels address a problem similar to “lock files” as implemented by some deployment tools—they let you pin and reproduce a set of packages. In the case of Guix though, you are effectively pinning the entire package set as defined at the given channel commits; in fact, you are pinning all of Guix, including its core modules and command-line tools. You’re also getting strong guarantees that you are, indeed, obtaining the exact same software.
This gives you super powers, allowing you to track the provenance of binary artifacts with very fine grain, and to reproduce software environments at will—some sort of “meta reproducibility” capabilities, if you will. Veja Inferiores, for another way to take advantage of these super powers.