de83fcb2df
The minimum reproduction for the problem I'm trying to solve is that
the following NixOS test with a trivial NixOS container:
```
{ inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/24.05";
flake-utils.url = "github:numtide/flake-utils/v1.0.0";
};
outputs = { flake-utils, nixpkgs, self, ... }:
flake-utils.lib.eachDefaultSystem (system: {
checks.default = nixpkgs.legacyPackages."${system}".nixosTest {
name = "test";
nodes.machine.containers.tutorial.config = { };
testScript = "";
};
});
}
```
… fails with the following error message:
```
error: Neither nodes.machine.nixpkgs.hostPlatform nor the legacy option nodes.machine.nixpkgs.system has been set.
You can set nodes.machine.nixpkgs.hostPlatform in hardware-configuration.nix by re-running
a recent version of nixos-generate-config.
The option nodes.machine.nixpkgs.system is still fully supported for NixOS 22.05 interoperability,
but will be deprecated in the future, so we recommend to set nodes.machine.nixpkgs.hostPlatform.
```
The root of the problem appears to be that in
`nixos/modules/virtualisation/nixos-containers.nix` there is support
for deriving the guest's `nixpkgs.hostPlatform` or
`nixpkgs.localSystem` from the corresponding host's values, but this
doesn't work if the host sets `nixpkgs.pkgs` instead of one of those
values. In fact, this is what happens when using `pkgs.nixosTest`
(which sets `nixpkgs.pkgs` in
`pkgs/build-support/testers/default.nix`).
The solution I went with was to forward the `nixpkgs.pkgs` setting from
the host to the guest, but only if it is defined (matching the same
treatment as `nixpkgs.hostPlatform` and `nixpkgs.localSystem`.
|
||
|---|---|---|
| .. | ||
| doc/manual | ||
| lib | ||
| maintainers | ||
| modules | ||
| tests | ||
| COPYING | ||
| default.nix | ||
| README.md | ||
| release-combined.nix | ||
| release-small.nix | ||
| release.nix | ||
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.
- CODEOWNERS 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 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 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 succeed on ARCHITECTURE
- [ ] 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