function nix-local-build
nix-build --no-out-link \
-E '(import <nixpkgs> {}).callPackage ./'$argv[1]' {}'
end
To build and install something I run: nix-local-build some.nix
nix-env -i [store-path-from-build]
The .nix file is in the same format as e.g. pkgs/tools/misc/bat/default.nix.Question 2 - How to include such a derivation into configuration.nix?
Question 2: including such a derivation is easy with overlays or with the method above.
drv = import ./path-to-derivation.nix;
package = pkgs.callPackage drv {};
or something similar can work. Overlays would be slightly more re-usable, but would take a few more expressions. I'd do that if there are multiple packages you need to introduce; I normally use overlays to manage groups of interdependent packages, a "meta-package".After you write a derivation that you can build, you need to create a module [1]. The module defines configuration options, then takes the donation and does other things such as creating service users (if needed), services and configurations.
Then you simply import it and use it.
Regarding question 1 what was suggested by others is what is the current way of doing it, but I will recommend to go through Nix Pills[2]. The author starts with making a simple derivation and then starts introducing conventions. The conventions make things more complex, but they make things more flexible. I can't wait for Flakes[3], they will standardize a lot of this, removing extra cruft and allowing things to be more composable.
[1] https://nixos.org/nixos/manual/index.html#sec-writing-module...
I've even read most Nix Pills posts, but didn't like them much. Too many details about things that I didn't understand at the time of reading, so the why got lost. In Nix you get a lot of details, what is missing is often the why and how. For example I wanted to have a CLI command available with a binary build, finding out how to add the CLI tool to the package through wrapProgram in postInstall wasn't fun. Overall Nix is awesome, but here and there it is hell of a lot frustrating. After reading so many hours I should not have to ask how to install a custom package the right way.
I have overlays in ~/.config/nixpkgs/overlays.nix (though you do this various ways)
My overlay file has the form:
let my-packages-overlay = self: super: { foo = super.callPackage ./path/to/package.nix {} } in [ my-packages-overlay ]
Then you can just nix-env -iA your-package.
This is what always gets me stuck. It seems like lots of tutorials assume you're installing packages by hand still. For me, the whole reason I'm using nix is so that I can use the declarative package management.
I get having local dev dependencies on a per-project basis and running a nix shell to make those dependencies available in your development environment.
But it's just confusing to me how many tutorials suggest running nix-env -i to imperatively install a package. Why would I do that instead of taking advantage of the joys of declarative package management?
So in many cases you are told to use nix-env, because the person just answered how to write a derivation and didn't go further than that.
I think flakes (still work in progress), will help here, because it defines a standard that supposed to do all of that in one file that is easily composable.