The ultimate goal I have is to include a package in my configuration, that isn’t in nixpkgs without having to fork nixpkgs. There is a very detailed answer on What shall I do if I want to add a package, but do not want to touch nixpkgs tree? however this is specific to a configuration.nix based setup.
To provide a little more context: I try to package GitHub - n4n0GH/hello: the complete KDE theme and have done so successfully in my configuration.nix-config. However the process was not straight-forward, because of the quirks of Qt5 in this case. With the help of this community I succeeded to package it though.
I now switched to a flake-based setup and tried to package the hello-theme “the flaky way”; i.e. by including the source via
however, I didn’t succeed in actually building the package. I’m using GitHub - gytis-ivaskevicius/flake-utils-plus: Use Nix flakes without any fluff. for my config and they have a property called sharedOverlays, where you can specify overlays that are automatically present on all configured channels. I tried to include the derivation I’ve built before like this:
sharedOverlays = [
(final: prev: {
hello-kde = prev.callPackage ./overlays/hello-kde.nix { pkgs=unstable; inherit hello-kde };
})
];
after adapting the derivation to have src = hello-kde, where hello-kde is the input from the flake. However this didn’t work and resulted in:
error: attribute 'libsForQt5' missing
Can anyone spot, where I’ve gone wrong there or clarify a better way of doing this? Is an overlay even the way to go in this case? You can find the current version of my (failing to build) configuration at GitHub - tim-hilt/nixos: My configuration-files for NixOS.
Thanks in advance!
Check out nix repl flake.nix. You can inspect the unstable argument of outputs as inputs.unstable – it is actually just an input so if you want to use packages from it, you will need unstable.legacyPackages.${system}. Or import unstable.outPath { inherit system; config = { /*…*/ }; } if you want to pass extra arguments to Nixpkgs. (You can omit outPath as that is implicit when import tries to stringify the attrset.)
Overlays are good idea for defining packages – they will allow you to add them on top of any base Nixpkgs repository (e.g. import unstable { inherit system; overlays = [ /*…*/ ]; }. Or at least they would, if they were a pure function (not using any values except those received by the final and prev arguments).
As it is now, you could just as well use unstable.legacyPackages.${system}.callPackage to make it clear that the prev.callPackage does not actually pass in any dependencies. Or you could just use plain old import since that prev.callPackage call does nothing more there. But I would probably go with the former since it would allow you to take libsForQt5 for argument, which is consistent with Nixpkgs style.
Personally, I would just create a pure overlay, instantiate unstable nixpkgs with it manually and use the packages I want to be based on unstable from there. But it looks like flake-utils-plus’s systemFlake function does not actually expose the sharedOverlays attribute so as long as you remain aware that the overlay is fixed, you will be fine.
Thanks for the reply! I didn’t actually know I could use unstable.legacyPackages.${system}.callPackage like this! Of course system was not defined, so I replaced it with x86_64-linux for my use-case.
However, when I tried nixos-rebuild switch, cmake began complaining. I filed this bug-report afterwards. This doesn’t seem to be related to my configuration-issue, but I can’t completely confirm that it’s working now, because of cmake being broken atm.