Here's the change I want to make but I'm not sure about, since I haven't seen anything similar in any other NixOS modules:

It'd make it so just setting services.synapse-bt.enable = true; would start without configuration.

diff --git a/nixos/modules/services/torrent/synapse-bt.nix b/nixos/modules/services/torrent/synapse-bt.nix
index e01f0d1a126..b282f4d3d37 100644
--- a/nixos/modules/services/torrent/synapse-bt.nix
+++ b/nixos/modules/services/torrent/synapse-bt.nix
@@ -28,7 +28,10 @@ in {
 
       config = mkOption {
         type = types.attrs;
-        default = {};
+        default = {
+          disk.session = "${stateDirectory}/session";
+          disk.directory = "${stateDirectory}/downloads";
+        };
         description = ''
           Configuration for synapse.toml. See
           <link xlink:href="https://github.com/Luminarys/synapse/blob/${pkgs.synapse-bt.version}/example_config.toml"/>
@@ -71,7 +74,7 @@ in {
     '';
   in mkIf cfg.enable {
     users.users.synapse-bt = mkIf (cfg.user == "synapse-bt") { group = mkDefault "synapse-bt"; };
-    users.groups.synapse-bt = mkIf (cfg.group == "synapse-bt") {};
+    users.groups.synapse-bt = mkIf (cfg.group == "synapse-bt") { };
 
     # for sycli
     environment.systemPackages = [ pkgs.synapse-bt ];
@@ -80,20 +83,28 @@ in {
       description = "Synapse BitTorrent daemon";
       wantedBy = [ "multi-user.target" ];
       after = [ "network.target" ];
-      preStart = mkIf (cfg.extraConfigPath != null) ''
+      preStart = ''
         touch ${stateDirectory}/synapse.toml
         chmod 600 ${stateDirectory}/synapse.toml
         ${pkgs.coreutils}/bin/cat \
             ${configFile} \
-            ${cfg.extraConfigPath} \
+            ${optionalString (cfg.extraConfigPath != null) cfg.extraConfigPath} \
             > ${stateDirectory}/synapse.toml
+        ${optionalString
+          (hasAttrByPath [ "disk" "session" ] cfg.config
+          && cfg.config.disk.session == "${stateDirectory}/session")
+          "mkdir -p ${stateDirectory}/session"}
+        ${optionalString
+          (hasAttrByPath [ "disk" "directory" ] cfg.config
+          && cfg.config.disk.directory == "${stateDirectory}/downloads")
+          "mkdir -p ${stateDirectory}/downloads"}
       '';
       serviceConfig = {
         User = cfg.user;
         Group = cfg.group;
         StateDirectory = "synapse-bt";
         ExecStart = ''
-          ${pkgs.synapse-bt}/bin/synapse -c ${if cfg.extraConfigPath != null then "${stateDirectory}/synapse.toml" else configFile}
+          ${pkgs.synapse-bt}/bin/synapse -c ${stateDirectory}/synapse.toml
         '';
       };
     };

Looking good! That simplifies the code nicely. Providing sane defaults is almost always the right choice as the less the user has to configure the better. A few suggestions if you go this route.

Instead of setting a default value for config you could do this inside the module implementation instead:

services.synapse-bt.config.disk = mapAttrs (name: mkDefault) {
  session = "${stateDirectory}/session";
  directory = "${stateDirectory}/downloads";
};

The benefit here is that your default disk options are merged with any user provided disk options.

You can omit your mkdir calls like so:

StateDirectory = [ "synapse-bt" ] ++ optional (hasAttrByPath ... && ==) cfg.config.disk.session ++ optional (hasAttrByPath ... && ==) cfg.config.disk.directory;

I would suggest that RuntimeDirectory might be a more appropriate location for your generated configuration file as it will be cleaned up after every service run.

Instead of setting a default value for config you could do this inside the module implementation instead

The reason I can't do this is that it causes this to be output to the configuration file:

[disk.directory]
_type = "override"
content = "/var/lib/synapse-bt/downloads"
priority = 1000

[disk.session]
_type = "override"
content = "/var/lib/synapse-bt/session"
priority = 1000

Right, I remember that now as I had tried doing that once. This would be an issue if users tried mkDefault or mkForce as well. I wonder what @infinisil would suggest as the author of RFC 42, because I can't seem to remember what the resolution to this was.

Ah yeah, the problem is the type of the option. types.attrs doesn't do the merging and defaulting stuff properly. This is why types for e.g. JSON are necessary as described here. So for now you can't have nested mkDefault's

What's the status? This service seems to be working ok.
I'm not sure if it looks uniform with transmission service, but it's probably not an issue.

Hello, I'm a bot and I thank you in the name of the community for your contributions.

Nixpkgs is a busy repository, and unfortunately sometimes PRs get left behind for too long. Nevertheless, we'd like to help committers reach the PRs that are still important. This PR has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

If this is still important to you and you'd like to remove the stale label, we ask that you leave a comment. Your comment can be as simple as "still important to me". But there's a bit more you can do:

If you received an approval by an unprivileged maintainer and you are just waiting for a merge, you can @ mention someone with merge permissions and ask them to help. You might be able to find someone relevant by using Git blame on the relevant files, or via GitHub's web interface. You can see if someone's a member of the nixpkgs-committers team, by hovering with the mouse over their username on the web interface, or by searching them directly on the list.

If your PR wasn't reviewed at all, it might help to find someone who's perhaps a user of the package or module you are changing, or alternatively, ask once more for a review by the maintainer of the package/module this is about. If you don't know any, you can use Git blame on the relevant files, or GitHub's web interface to find someone who touched the relevant files in the past.

If your PR has had reviews and nevertheless got stale, make sure you've responded to all of the reviewer's requests / questions. Usually when PR authors show responsibility and dedication, reviewers (privileged or not) show dedication as well. If you've pushed a change, it's possible the reviewer wasn't notified about your push via email, so you can always officially request them for a review, or just @ mention them and say you've addressed their comments.

Lastly, you can always ask for help at our Discourse Forum, or more specifically, at this thread or at #nixos' IRC channel.

Any chance of this being merged?

A fair bit has changed in nixpkgs since this was worked on last. @tadeokondrak do you have any interest in continuing with this PR?

@ZoomRmc if not, do you have any interest in continuing this PR instead?

I marked this as stale due to inactivity. → More info

I'm curious about this. What has to be addressed in order to get this merged?

@LoveIsGrief someone (you?) would have to take this code and start a new PR. This is pretty old so a few changes would be required to keep up with evolving module standards.

Taking a brief look at the code these are the two that appear relevant:

• https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md
• https://github.com/NixOS/rfcs/blob/master/rfcs/0052-dynamic-ids.md

Please feel free to open a new PR. It shouldn't be too much work.

Closing because the PR is stale and the original author did not react in over a year.