5 ms·
Question 1 - What is the correct way to build and install self created derivations? Right now I have a custom fish function: function nix-local-build nix
by thibran 6y ago
Question 1 - What is the correct way to build and install self created derivations? Right now I have a custom fish function:
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?
- nomurrcy 6y agoOverlays can be very helpful for this type of thing. 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. See: https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays
- mason55 6y ago> 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?
- nvarsj 6y agoI've never used nix-env on NixOS. I really think that command only exists as a bridge for people used to more traditional OS's. I think there is a space for it - if you don't want to spend time building your user configuration declaratively, just install what you need and get going.
- takeda 6y agoBecause Nix is a language there are many ways of accomplishing the same thing. Some ways are easier, some require more work. For example if you make a derivation in your home, it is easy to install it with nix-env from there, and you are done, but if you want to include it in your configuration, you typically would create an overlay that includes your package in nixpkgs. Then you can list the package. If your derivation requires creating a configuration, service etc. On top of that you will also need to create module that specifies configuration options and configures the application. 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.
- tomberek 6y agoQuestion 1: That is a reasonable way to build and install. I normally structure things like this (https://www.reddit.com/r/NixOS/comments/8tkllx/standard_project_structure/ https://www.reddit.com/r/NixOS/comments/8tkllx/standard_proj...) where the Nixpkgs-compatible derivation is in derivation.nix and the default.nix or overlay.nix contains the "callPackage" portion. 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".
- thibran 6y agoThanks a lot for this :)
- takeda 6y agoJust to add to what others said regarding question 2. 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-modules https://nixos.org/nixos/manual/index.html#sec-writing-module... [2] https://nixos.org/nixos/nix-pills/index.html https://nixos.org/nixos/nix-pills/index.html [3] https://www.tweag.io/blog/2020-05-25-flakes/ https://www.tweag.io/blog/2020-05-25-flakes/
- thibran 6y agoThanks for the links. Flakes seem to be a good way forward. 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.