Potential RFC Idea: `Exec(Start|Stop)(Pre|Post)` as lists

Development RFCs
1

Hi!
I often find useful to add some ExecStartPre (and siblings) commands to existing services, as a way to extend them, perform custom actions, etc.

However, I’m often impeached by existing commands declared like so in their upsteam module:

{ ExecStartPre = "some action"; }

… that prevent any other ExecStartPre command to be added later.
On the opposite, declaring them this way permits extensibility in personal configurations:

{ ExecStartPre = [ "some action" ]; }

… permitting to add other command lists that will be merged by the nixos module system.

Is there any issue with declaring them always as lists? I can’t figure any.

If not, what would be the better action to address this issue?

  • Should I create a tree-wide commit that enforce declarations in brackets?
  • Should I create a RFC, to change the nixos systemd module so that it deprecate non-list usage?

Thanks for reading!

6 Likes
2

I don’t think this needs an RFC. RFCs are only necessary for “substantial” changes.

In this case I think we just need to always coerce definitions to lists, probably by changing unitOption (which should really be unitType) to just

unitOption =
  let
    atom = types.oneOf [
      types.bool
      types.str
      types.int
    ];
  in types.coercedTo atom singleton (listOf atom)

I’m not sure if these three atomic types are complete though, would need to be tested.

We can then maybe also simplify this line.

3 Likes
3

I want to add ExecReload to the list (hehe)!
Just recently ran into the case of wanting exactly this.

1 Like
4

That would be awesome! This way, no changes are required in the upstream modules.

Should I open a PR to make this change, as I’m not as confident with nix and nixpkgs?