Overlays don't "provide any options". Overlays simply extend nixpkgs or replace parts of it. You can search through all packages in nixpkgs here.
nixos
All about NixOS - https://nixos.org/
There are no standardised options like you're looking for to be found in overlays. Overlays allow "editing" the package set by constructing a new package set where one (or multiple) package(s) is/are different, that's it.
An Individual package can be "edited" to be the same package but slightly different by using its override function. It allows you to change the package's parameters. I.e. overriding one dependency with another. Some packages might provide configuration flags in their arguments but they're in no way uniform and always specific to the package. They're also not guaranteed to be stable.
To change a package, you must look at the package's definition to see what could be changed about it. Overlays are just the way to apply that change to the entire package set.
So If I am understanding this, Overlays are a way to apply changes to the package via its definition using already existing mentions like overriding and such then propagating those changes outside to an entire set of packages.
Overlays allow any modification you can think of, not just limited to what packages have as "override options". You could say firefox = final.hello
and then building pkgs.firefox would then result in hello. You could also say firefox = final.callPackage { } ...
to inject a whole new derivation you've written yourself. You could make firefox = "foo"
if you wanted to (not that that'd make any sense to do).
firefox = prev.firefox.override { ... }
is just the specific case where you set the firefox package to its overridden variant (.override returns a new derivation).
That's everything as far as overlays are concerned.
The other piece to this puzzle are overrides. Overrides are a function of each derivation that returns a modified version of the derivation. You can override parameters (a package definition is usually a function) or the attributes of the mkDerivation
call. The former obviously relies on the derivation having some flags you could change in its parameters while the latter can do anything you could do in a mkDerivation
call (adding additional patches, using a different src, running some more commands preInstall etc.).
You can use overrides without overlays. If all you want is a leaf package but slightly different in your systemPackages, you could do that directly where you set it:
environment.systemPackages = [
(firefox.override { ... })
hello
whatever
...
];
Overlays come into play when you want to have dependants of the package to also use the overridden variant without having to explicitly inject it via another override every time or need to modify some service's package that you didn't set yourself (most offer an option to change the package used but some don't).
So we need to unpack two things here
options
is what you typically need to specify in your configuration.nix
or via home-manager.
They can be found here
Overlays are mostly used to overwrite attributes or build inputs, eg. (final: prev: { foo = prev.foo.override { bar = "baz"; }; })
Now I am not particularly sure about how home-manager and neovim work together, but it looks like the module takes an option to set the program, so I'd consider just plucking your neovim-qt program right in there.
Inside of this example would the sets that are changeable inside of .override like bar for example be the definitions made within the .nix file for a respective package? I'm trying to understand how I know what can be overridden.
You can override derivation inputs and derivation attributes. Let's take for example the nano editor.
You can enable tidy support by overriding the enableTidy
input like so:
(final: prev: { nano = prev.nano.override { enableTidy = true; }; })
You can also override build steps, eg. if you want to apply an upstream patch because you don't want to wait for the next release version, you'd do it like this.
(final: prev: { nano = prev.nano.overrideAttrs ( old: { patches = (old.patches or [] ) ++ [ ./filename.patch ]; }); })
Now the thing about overlays is this: if you change a package in an overlay, all packages depending on that package, either directly or indirectly, will pull in that modified version, which is an extremely powerful tool as you can probably imagine.
It all makes sense now!
enableTidy
I recently had a chance to take a look at the nano.nix file on github responsible for building nano. But I don't see where the enableTidy attribute is declared did you mean enableTiny by any chance?
Yes, I do mean enableTiny
. Sorry about the confusion :)