After d95261b435, the following flake.nix fails:
```nix
{
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
outputs = { nixpkgs, ... }: {
nixosConfigurations.demo = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
({ lib, ... }: {
boot.loader.grub.enable = false;
fileSystems."/" = { device = "none"; fsType = "tmpfs"; };
nixpkgs.config.packageOverrides =
lib.mkIf false (_: { });
})
];
};
};
}
```
This is the error:
```
$ nix build /tmp/tmp.vWEVitTgK9/#nixosConfigurations.demo.config.system.build.toplevel
evaluation warning: system.stateVersion is not set, defaulting to 26.05. Read why this matters on https://nixos.org/manual/nixos/stable/options.html#opt-system.stateVersion.
error:
… while calling the 'derivationStrict' builtin
at <nix/derivation-internal.nix>:37:12:
36|
37| strict = derivationStrict drvAttrs;
| ^
38|
… while evaluating derivation 'nixos-system-nixos-26.05.20260409.4c1018d'
whose name attribute is located at /nix/store/anvdcc2arw7kqrvwnidvhw6ypkkvws68-source/pkgs/stdenv/generic/make-derivation.nix:541:11
… while evaluating attribute 'buildCommand' of derivation 'nixos-system-nixos-26.05.20260409.4c1018d'
at /nix/store/anvdcc2arw7kqrvwnidvhw6ypkkvws68-source/nixos/modules/system/activation/top-level.nix:64:7:
63| passAsFile = [ "extraDependencies" ];
64| buildCommand = systemBuilder;
| ^
65|
… while evaluating the option `environment.etc.dbus-1.source':
… while evaluating the default value of option `pythonTestDriverPackage`
… while evaluating the module argument `hostPkgs' in "/nix/store/anvdcc2arw7kqrvwnidvhw6ypkkvws68-source/nixos/lib/testing/driver.nix":
… noting that argument `hostPkgs` is not externally provided, so querying `_module.args` instead, requiring `config`
… while evaluating the option `hostPkgs':
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: The option `hostPkgs' was accessed but has no value defined. Try setting the option.
```
Setting a `defaultText` fixes the issue.
I've also added a regression test under `nixos/tests/nixos-test-driver/` and
fixed a typo in the option description ("implemetnation").
NixOS
NixOS is a Linux distribution based on the purely functional package management system Nix. More information can be found at https://nixos.org/nixos and in the manual in doc/manual.
Testing changes
You can add new module to your NixOS configuration file (usually it’s /etc/nixos/configuration.nix).
And do sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast.
Commit conventions
-
Make sure you read about the commit conventions common to Nixpkgs as a whole.
-
Format the commit messages in the following way:
nixos/(module): (init module | add setting | refactor | etc) (Motivation for change. Link to release notes. Additional information.)Examples:
-
nixos/hydra: add bazBaz option
Dual baz behavior is needed to do foo.
-
nixos/nginx: refactor config generation
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
-
Reviewing contributions
When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people’s installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
Module updates
Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.
Reviewing process:
- Ensure that the module maintainers are notified.
- The continuous integration system will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
- Ensure that the module tests, if any, are succeeding.
- You may invoke OfBorg with
@ofborg test <module>to buildnixosTests.<module>
- You may invoke OfBorg with
- Ensure that the introduced options are correct.
- Type should be appropriate (string related types differs in their merging capabilities,
loaOfandstringtypes are deprecated). - Description, default and example should be provided.
- Type should be appropriate (string related types differs in their merging capabilities,
- Ensure that option changes are backward compatible.
mkRenamedOptionModuleWithprovides a way to make renamed option backward compatible.- Use
lib.versionAtLeast config.system.stateVersion "24.05"on backward incompatible changes which may corrupt, change or update the state stored on existing setups.
- Ensure that removed options are declared with
mkRemovedOptionModule. - Ensure that changes that are not backward compatible are mentioned in release notes.
- Ensure that documentations affected by the change is updated.
Sample template for a module update review is provided below.
##### Reviewed points
- [ ] changes are backward compatible
- [ ] removed options are declared with `mkRemovedOptionModule`
- [ ] changes that are not backward compatible are documented in release notes
- [ ] module tests succeed on ARCHITECTURE
- [ ] options types are appropriate
- [ ] options description is set
- [ ] options example is provided
- [ ] documentation affected by the changes is updated
##### Possible improvements
##### Comments
New modules
New modules submissions introduce a new module to NixOS.
Reviewing process:
- Ensure that all file paths fit the guidelines.
- Ensure that the module tests, if any, are succeeding.
- Ensure that new module tests are added to the package
passthru.tests. - Ensure that the introduced options are correct.
- Type should be appropriate (string related types differs in their merging capabilities,
loaOfandstringtypes are deprecated). - Description, default and example should be provided.
- Defaults may only be omitted if both:
- The user is required to set the default in order to properly use the service.
- The lack of a default does not break evaluation when the module is not enabled.
- Defaults may only be omitted if both:
- Type should be appropriate (string related types differs in their merging capabilities,
- Ensure that module
metafield is present- Maintainers should be declared in
meta.maintainers. - Module documentation should be declared with
meta.doc.
- Maintainers should be declared in
- Ensure that the module respect other modules functionality.
- For example, enabling a module should not open firewall ports by default.
Sample template for a new module review is provided below.
##### Reviewed points
- [ ] module path fits the guidelines
- [ ] module tests, if any, succeed on ARCHITECTURE
- [ ] module tests, if any, are added to package `passthru.tests`
- [ ] options have appropriate types
- [ ] options have default
- [ ] options have example
- [ ] options have descriptions
- [ ] No unneeded package is added to `environment.systemPackages`
- [ ] `meta.maintainers` is set
- [ ] module documentation is declared in `meta.doc`
##### Possible improvements
##### Comments
See also ./README-modular-services.md.