stylix: add testbeds for desktop environments

[danth]

First stage of #319.

This allows a NixOS configuration to be defined for any target by creating a file named testbed.nix in the target directory.

For each testbed.nix, we generate two virtual machines:

• One with a light theme, currently Catppuccin Latte
• One with a dark theme, currently Catppuccin Macchiato

TODOs for this PR:

• Finalise naming. Currently the machines are referred to as "checks", following the name of the standard flake output for test packages.

[danth]

Testbed

A testbed is a platform for conducting rigorous, transparent, and replicable testing of scientific theories, computing tools, and new technologies.

[trueNAHO]

Great job!

Should we add a central testbed package that runs all other testbed-${testbed.name}-${stylix.polarity} packages? This would avoid a complicated nix flake show | <PARSING> | nix run command and the following boilerplate test script:

nix run .#testbed-gnome-dark
nix run .#testbed-gnome-light
nix run .#testbed-kde-dark
nix run .#testbed-kde-light

The pkgs.buildEnv function allows merging the outputs of a list of derivations.

For reference, I have used pkgs.buildEnv for a similar use case at: https://github.com/trueNAHO/asciidoctor.nix/blob/8ed50e9bdeaede79753ff7656d82fbc12cddc191/flake.nix#L124-L127.

Alternatively, we could simply add the testbed-${testbed.name}-${stylix.polarity} packages to the checks output. This approach might be better than the nix run approach.

[danth]

This depends on #330 since it uses a file name with a space

[danth]

Alternatively, we could simply add the testbed-${testbed.name}-${stylix.polarity} packages to the checks output. This approach might be better than the nix run approach.

These are meant for manual testing, since they open a virtual machine where you can mess around with the application and check the styling. Hence it's important to be able to run an individual testbed as easily as possible.

Using the checks output, to run a testbed you would have to type nix run .#checks.x86_64-linux.testbed-gnome-light, rather than simply nix run .#testbed-gnome-light when they are under packages.

(The testbeds are also built on GitHub Actions, but this is only to pick up on obvious build failures. It's still necessary to do a manual check to see whether anything changed visually.)

Should we add a central testbed package that runs all other testbed-${testbed.name}-${stylix.polarity} packages? This would avoid a complicated nix flake show | | nix run command

As mentioned above, running these opens a virtual machine, so it doesn't make sense to run a large number at once like that.

[trueNAHO]

These are meant for manual testing, since they open a virtual machine where you can mess around with the application and check the styling. Hence it's important to be able to run an individual testbed as easily as possible.

Should we add a central testbed package that runs all other testbed-${testbed.name}-${stylix.polarity} packages? This would avoid a complicated nix flake show | | nix run command

As mentioned above, running these opens a virtual machine, so it doesn't make sense to run a large number at once like that.

I discovered enableParallelBuilding today: NixOS/nixpkgs#142338. Do you think we could incorporate this here to speed up the execution time of testing? Considering they are meant for manual testing, parallelizing them would not be good.