nix-book/source/recipes/build/nix-non-flake/main.adoc0
Amy de Buitléir e9e4271a47 temp
2025-09-15 15:59:46 +01:00

60 lines
1.7 KiB
Text

= Access a non-flake package (not in nixpkgs)
////
$ 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 nix package (not a flake) defined in a remote git repo.
However, you can use any of the flake reference styles defined in <<#flakeref>>.
We already covered how to add a non-flake input to a flake and build it in <<#devshell-nix-non-flake>>;
here we will focus on making it available at runtime.
We will write a flake to package a very simple shell script.
All it does is invoke `hello-nix`, which is the input we added <<#devshell-nix-non-flake,earlier>>.
[source,bash,linenums]
.hello-again
....
$# cat hello-again
....
[source,nix,linenums,highlight='5..8,15,34..36,40']
.flake.nix
....
$# cat flake.nix
....
Lines 5-8 and 15 were explained in <<#devshell-nix-non-flake>>.
As expected, we need to add `helloNix` as a build input, which we do in line 40.
That does make it 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 34-36) 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
////