nix-book/source/recipes/build/flake/main.adoc0
Amy de Buitléir 1ad9b077c4 initial commit
2025-09-15 17:40:48 +01:00

67 lines
1.9 KiB
Text

= Access a flake
////
$ mkdir tempwork
$ cd tempwork
$ cp ../hello-again ../flake.nix .
$ git add hello-again flake.nix
$ nix build
$ git add flake.lock
$ git commit -a -m temp
////
In this example, we will use a flake defined in a remote git repo.
However, you can use any of the flake reference styles defined in <<#flakeref>>.
[source,bash,linenums]
.hello-again
....
$# cat hello-again
....
[source,nix,linenums,highlight='5,8,30..32,35']
.flake.nix
....
$# cat flake.nix
....
Line 5 adds `hello-flake` as an input to this flake,
Line 8 allows the output function to reference `hello-flake`.
As expected, we need to add `hello-flake` as a build input, which we do in line 35.
Let's take a closer look at the `buildInputs` expression from line 35.
....
$# grep buildInputs flake.nix | sed 's/ //g; s/.*\[//; s/\].*//'
....
Why is the first part `hello-flake` and the last part `hello`?
The first part refers to the name we assigned in the input section of our flake,
and the last part is the name of the package or app we want.
(See <<_flake_outputs>> for how to identify flake outputs.)
Line 35 does make `hello-flake` available at build and runtime,
but it doesn't put it on the path,
so our `hello-again` script won't be able to find it.
There are various ways to deal with this problem.
In this case we simply edited the script (lines 30-32) as we install it,
by specifying the full path to `hello-nix`.
[NOTE]
====
When you're packaging a program written in a more powerful language such as
Haskell, Python, Java, C, C#, or Rust,
the language build system will usually do all that is required
to make the dependencies visible to the program at runtime.
In that case, adding the dependency to `buildInputs` is sufficient.
====
Here's a demonstration using the flake.
....
$ nix run
....
////
Good adoc0 scripts clean up after themselves.
$ cd .. ; rm -rf tempwork # clean up
////