Because of how the command evaluation is structured, care must be taken with characters that bash might interpret, in particular `'`, `;`, and `|`, which may need escaping to `\'`, `\;`, and `\|` respectively.

Because of how the command evaluation is structured, care must be taken with characters that bash might interpret, escaping them where necessary.

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Putting wttr-delft into a container as a small static binary
, We now combine our knowledge of making OCI containers with our knowledge of making static binaries

h "Putting wttr-delft into a container as a small static binary"
, "We now combine our knowledge of making OCI containers with our knowledge of making static binaries"

h Build the container

h "Build the container"

n It\'s a lot smaller than before!

n "It's a lot smaller than before!"

h All done with this part!
p

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Now we are inside a development shell that has rootless podman again.
, We repeat what we did earlier:

h "Now we are inside a development shell that has rootless podman again."
, "We repeat what we did earlier:"

h We start by loading the container we just made into the registry:

h "We start by loading the container we just made into the registry:"

h We can see it\'s there, and it\'s tiny!

h "We can see it's there, and it's tiny!"

h And now we can run it:

h "And now we can run it:"

h We have running containers:

h "We have running containers:"

h Let\'s kill them and remove them:

h "Let's kill them and remove them to clean up after ourselves..."

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Adding CMake

h "Adding CMake"

n The more we offload to \'classic\' tools, the easier it is to also build without Nix.
, This makes it an easier sell to use in most cases\; other people are not forced to use it.
, Packaging in this way and making use of the sandboxed Nix build process
, can help find dependencies that were not correctly declared etc.

n "The more we offload to 'classic' tools, the easier it is to also build without Nix."
, "This makes it an easier sell to use in most cases; other people are not forced to use it,"
, "but can use the shared build system in their own environment if so desired."
, "Packaging in this way and making use of the sandboxed Nix build process"
, "can help find dependencies that were not correctly declared etc."

n If we add a proper build system like CMake, the Nix part of building a package gets even easier.

n "If we add a proper build system like CMake, the Nix part of building a package gets even easier:"

h Cross-compilation
, The previous build was for x86_64-linux by default because that is our current system:

h "Cross-compilation"
, "The previous build was for x86_64-linux by default because that is our current system:"

h We can very easily set up cross-compilation.
, We use the \'flake-utils\' library to abstract away some of the complications in the flake:

h "We can very easily set up cross-compilation:"
, "We use the 'flake-utils' library to abstract away some of the complications in the flake:"
, "This also demonstrates how easy it is to combine flakes."

, Now we can call a different output:

, "Now we can call a different output:"

, And this is indeed a RISC-V binary:

, "And this is indeed a RISC-V binary:"

h Static executables
, We can also cross compile a static build:

h "Static executables"
, "We can also cross compile a static build:"

, And this is indeed a static binary:

, "And this is indeed a static binary:"

h Everything together
, Static cross compiled for aarch64-linux - you can copy this executable and run it on a Raspberry Pi!

h "Everything together"
, "Static cross compiled binary for aarch64-linux - you can copy this executable and run it on a Raspberry Pi!"

h Emulation
, If we take a look at what the flake provides we see multiple architectures as well:

h "Emulation"
, "If we take a look at what the flake provides we see multiple architectures as well:"

n This will not work if the emulation is not available:
, But, if you use NixOS it\'s also very simple to set up binfmt to emulate e.g. aarch64-linux!

n "This will not work if the emulation is not available:"
, "But, if you use NixOS it's also very simple to set up binfmt to emulate e.g. aarch64-linux!"

, And we can actually run it as well!

, "And we can actually run it as well"

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Putting wttr-delft into a container
, Expanding on the previous nix flake makes building a OCI compliant \(Docker\) image easy:

h "Putting wttr-delft into a container"
, "Expanding on the previous nix flake makes building a OCI compliant (Docker) image easy:"

h We now choose the \'container\' package we defined:

h "We now choose the 'container' package we defined:"

, "Let's rebuild so we can see what happened..."
, "This is a 'layered' image, so we might be able to re-use layers at the Docker level."

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Now we are inside a development shell that has rootless podman.
, We can manipulate containers just like docker could.

h "Now we are inside a development shell that has rootless podman."
, "We can manipulate containers just like docker could."

n We have added the \'dockerCompat\' package so we can use the \'docker\' command instead of \'podman\'.

n "We have added the 'dockerCompat' package so we can use the 'docker' command instead of 'podman'."
, "In this demo we use it interchangably just to show we can."

h So we start by loading the container we just made into the registry:

h "So we start by loading the container we just made into the registry:"

h We can see it\'s there:

h "We can see it's there:"

h And now we can run it:

h "And now we can run it:"

h The image is somewhat minimal, e.g. there is no interactive shell:

h "The image is somewhat minimal, e.g. there is no interactive shell:"

h We have running containers:

h "We have running containers:"

h Let\'s kill them and remove them:

h "Let's kill them and remove them to clean up after ourselves..."

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Making our own wttr-delft package
, For some reason, we want to have a simple C package that explicitly gets the weather in Delft.
, We\'re going to use \'libcurl\' for this, and build the executable using nix.

h "Making our own wttr-delft package"
, "For some reason, we want to have a simple C package that explicitly gets the weather in Delft."
, "We're going to use 'libcurl' for this, and build the executable using nix."

h The source code is taken from https://curl.se/libcurl/c/simple.html

h "The source code is taken from https://curl.se/libcurl/c/simple.html"

h Using a Nix flake
, The modern \(experimental, but recommended\) way to use Nix is to use \'flakes\':

h "Using a Nix flake"
, "The modern (experimental, but recommended) way to use Nix is to use 'flakes':"

, Flakes are the unit for packaging Nix code in a reproducible and discoverable way.
, They can have dependencies on other flakes, making it possible to have multi-repository Nix projects.
, A flake is a filesystem tree \(typically fetched from a Git repository or a tarball\)
, that contains a file named flake.nix in the root directory.
, flake.nix specifies some metadata about the flake such as dependencies \(called inputs\),
, as well as its outputs \(the Nix values such as packages or NixOS modules provided by the flake\).

, "Flakes are the unit for packaging Nix code in a reproducible and discoverable way."
, "They can have dependencies on other flakes, making it possible to have multi-repository Nix projects."
, "A flake is a filesystem tree (typically fetched from a Git repository or a tarball)"
, "that contains a file named flake.nix in the root directory."
, "flake.nix specifies some metadata about the flake such as dependencies (called inputs),"
, "as well as its outputs (the Nix values such as packages or NixOS modules provided by the flake)."

h So, what does a flake look like?

h "So, what does a flake look like?"

h Any inputs are pinned with a lock file

h "Any inputs are pinned with a lock file"

h So, without further ado, let\'s build our package:

h "So, without further ado, let's build our package:"

h Maybe there was no output\; this means that package was already built and put into the Nix store

h "Maybe there was no output; this means that package was already built and put into the Nix store"
, "Let's build it again so we can see what happens under the hood"

h By default, we get a ./result symlink in the current working directory
x find -L "./result"

h "By default, we get a ./result symlink in the current working directory that points to the result of our build:"
x readlink -f ./result
x find -L "$(readlink -f ./result)"

h And we can run our executable

h "And we can run our executable"

h We can also just run the executable directly with \'nix run\'

h "We can also just run the executable directly with 'nix run'"

h If we want to do development, we also get that \'for free\' with \'nix develop\':
n We do not have gcc available at the moment!

h "If we want to do development, we also get that 'for free' with 'nix develop':"
n "We do not have gcc available at the moment!"

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Now we are inside a nix-develop shell!

h "Now we are inside a nix-develop shell!"

n We started this script to continue the demo\; for normal use \'nix develop\' will drop you into a shell.

n "We started this script to continue the demo; for normal use 'nix develop' will drop you into a shell."

h And we do have gcc:

h "And we do have gcc:"

h Not only that, but Nix does all sorts of clever things such as wrapping the compiler:

h "Not only that, but Nix does all sorts of clever things such as wrapping the compiler:"

h So that required libraries etc. are available:

h "So that required libraries etc. are available:"

h And we can in fact build:

h "And we can in fact build:"

h And run!

h "And run!"

dir="$(dirname "${BASH_SOURCE[0]}")"

dir="$(realpath --relative-to="${PWD}" "$(dirname "${BASH_SOURCE[0]}")")"

h Getting the weather
, With Docker we might use \'docker run curlimages/curl wttr.in/Delft\'\;
, with Nix we can use

h "Getting the weather"
, "With Docker we might use 'docker run curlimages/curl wttr.in/Delft';"
, "with Nix we can use the following command:"

n \'nixpkgs\' is a shorthand way to refer to the main Nix package repository.

n "'nixpkgs' is a shorthand way to refer to the main Nix package repository."

h But we may already have had curl on our path?

h "But we may already have had curl on our path?"

h So to prove \'nix run\' works:

h "So to prove 'nix run' actually works, choose a package we don't already have:"

n In the curl example we were playing fast and loose: the nix run command would just take the latest version.
n But for cowsay, we pinned it to a particular revision of nixpkgs.

n "In the curl example we were playing fast and loose: the nix run command would just take the latest version."
n "But for cowsay, we pinned it to a particular revision of nixpkgs."