@rasmus-kirk what I gather from the source it downloads the specified version from Github which is already compiled with the hardcoded path. And since this compiled version of this project is just a bunch of files, served by Transmission, there is no way it can consume or use any environment variables. On top of that Transmission will only serve files which are in the same folder as the code, so you will still be limited by that.

I'm not fully aware of the in and outs of Nix (though I know some basics) do you perhaps know a bit more how this could be done given the above contraints?

The Nix package actually builds it from source - fetchFromGitHub downloads the source tarball and buildNpmPackage handles the build. (I'm the maintainer of flood-for-transmission in nixpkgs).

I could add a floodSettings parameter to the derivation which could be used to override the configuration. You could use it like this (though it would cause flood-for-transmission to be rebuilt):

{ pkgs, ... }:
{
  services.transmission = {
    enable = true;
    package = pkgs.transmission_4;
    webHome = pkgs.flood-for-transmission.override {
      floodSettings.SWITCH_COLORS = true;
    };
}

Thanks a lot for you input @al3xtjames in that case using environment variables for all the individual configuration values could solve this problem. I can explore this a little and see if it would work. I can ping in this issue if I need some support with testing my solution.

(please be patient with me on the implementation, I might not get around to this very soon)

@al3xtjames @rasmus-kirk I actually found some time and inspiration to look at this a bit more and implemented the feature in the linked PR. Would either (or even both) be willing to test this out to see if it fulfills the requirements?

I tried it out and it works, but I'm not sure if this is an improvement as the environment variables need to be set at build time. In nixpkgs you'd still need to override the package which results in a rebuild. IMO it would be nice if the environment variables could be read at runtime, though I'm not sure if this would introduce additional complexity. That way you could do something like this to configure Flood without having to rebuild flood-for-transmission:

{ config, pkgs, ... }:

let
  cfg = config.services.transmission;
in {
  systemd.services.transmission.environment = {
    FLOOD_COMMON_PATH = "[${cfg.settings.download-dir}]";
    FLOOD_SORT_COLUMN = "Name";
    FLOOD_SORT_DIRECTION = "asc";
    FLOOD_SWITCH_COLORS = "true";
  };

  services.transmission = {
    enable = true;
    package = pkgs.transmission_4;
    webHome = pkgs.flood-for-transmission;
  };
}

BTW, I managed to add a parameter for the config to the Nix package which generates config.json at build time. You can use it like this:

{ config, pkgs, ... }:

let
  cfg = config.services.transmission;
in {
  services.transmission = {
    enable = true;
    package = pkgs.transmission_4;
    webHome = pkgs.flood-for-transmission.override {
      floodSettings = {
        COMMON_PATH = [ cfg.settings.download-dir ];
        SORT_COLUMN = "Name";
        SORT_DIRECTION = "asc";
        SWITCH_COLORS = true;
      };
    };
  };
}

@al3xtjames sadly this is a limitation of how the application is build. After build time Flood for Transmission is merely an HTML file with some JS file loaded into it. There is no process at all, meaning it's impossible to read environment variables from the machine when loading the page with the browser.

Perhaps your solution is more elegant to the problem, it at least reduces the different configurations I will have to maintain in the applications and on top of that you won't have to rebuild the application when the config changes.

What do you think?

That makes sense, I suspected there was a limitation like that. I can work on getting this submitted to nixpkgs.