dev/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
11376df6d4
nixpkgs/nixos
History
Maximilian Bosch 11376df6d4
nixos/rust-motd: allow ordering sections by priority 
Closes #234802

The problem here is that with e.g.

    {
      uptime.prefix = "Up";
      banner.command = "hostname | figlet -f slant";
    }

`banner` still appears before `uptime` in the final motd text because
Nix sorts attribute names alphabetically internally.

To work around this without breaking compatibility or losing the
property to override individual sections in other modules - e.g.

    {
      banner.color = mkForce "blue";
    }

I decided to introduce an option `priority` here, similar to the
priority field for `nginx`[1] and with the same semantics (i.e. higher
value means lower priority).

Internally a bunch of env vars are generated, i.e. `env0` to `envN` for
`N` sections with each of them containing a declaration for the TOML,
i.e. `env0` contains `{ uptime.prefix = "Up"; }` and `env1` contains
`{ banner.command = "hostname | figlet -f slant"; }` if `uptime.priority`
is set to a value below 1000.

In this order, the declarations are concatenated together by `jq(1)`
which doesn't sort keys alphabetically which results in a JSON
representation with `uptime` before `banner`. This is finally piped to
`json2toml` which converts this into TOML for rust-motd.

[1] https://nixos.org/manual/nixos/unstable/options#opt-services.nginx.virtualHosts._name_.locations._name_.priority
2023-09-21 13:17:13 +02:00
..
doc/manual Merge pull request #253876 from nbraud/nixos/sudo-rs 2023-09-20 13:55:33 +02:00
lib Merge pull request #253876 from nbraud/nixos/sudo-rs 2023-09-20 13:55:33 +02:00
maintainers nixos/lxd: add virtual-machine support, image and module 2023-09-03 20:06:44 -04:00
modules nixos/rust-motd: allow ordering sections by priority 2023-09-21 13:17:13 +02:00
tests nixosTests.sudo-rs: fix syntax 2023-09-20 13:58:08 +02:00
COPYING
default.nix
README.md CONTRIBUTING.md: Move boot loader-specific sentence to pkgs/README.md 2023-08-14 19:50:02 +02:00
release-combined.nix nixos/release-combined.nix: Build pkgs/by-name tester 2023-08-29 16:35:07 +02:00
release-small.nix
release.nix Merge pull request #244093 from adamcstephens/lxd/vm 2023-09-03 22:02:54 -05:00

README.md

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.

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.
  • Ensure that the introduced options are correct.
    • Type should be appropriate (string related types differs in their merging capabilities, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that option changes are backward compatible.
    • mkRenamedOptionModuleWith provides a way to make option changes backward compatible.
  • 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 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, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that module meta field is present
    • Maintainers should be declared in meta.maintainers.
    • Module documentation should be declared with meta.doc.
  • 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