I don't think it's that bad: I mean, if we'd talk about the sizes of *-packages.nix, then I'd agree (because most editors and LSPs are getting horribly slow then), but this doesn't seem to be the case here. Also, in languages with rather underdeveloped editor integrations I think splitting things off prematurely only makes it harder to find stuff IMHO. I think there's a reasonable boundary though: the current module is responsible for setting up synapse itself (including workers) which is tightly coupled (because e.g. the systemd units are quite similar). If we come up with a good design for setting up load balancing w/ nginx of HTTP locations to workers and/or the main process, then we'd have something that clearly belongs into its own file. Also, if the module becomes too complex eventually, we can also consider moving the options into its own file (right now we wouldn't gain much from it because the majority of the file consists of options).

The only difference left is probably that I use workers.instances and this one does just pure workers like was suggested. This is fine, I can just use autoWorkers or something for part 2

It used to be a level deeper, but I suggested to remove it (there was an enable option as well, but instead workers != {} is used as enable condition now).
And yeah, autoWorkers for more fancy / high-level stuff seems reasonable, that makes the distinction quite clear: one is there to actually define a worker, the other is there to declare what kinds of workers you need (i.e. one level higher) if I understood your proposal correctly. Not sure if there's better naming, but that'd be a detail to figure out then.

I'm still interested in your additional patches (just declaring that one needs N workers doing X and M workers doing Y seems pretty cool. Not sure if we'll find a reasonable abstraction for the nginx part w/o rfc42 for nginx, but we'll see and I'm happy to discuss this in a github issue first if you're not sure - asynchronous discussion is preferred over chat for that).

I think this is a very big step forward now (after supporting synapse for a long time, one can trivially set up workers on NixOS now without knowledge about the inner workings of the synapse module - knowing how to write Nix and (basic) knowledge about synapse configuration is sufficient; it's type-checked, validated & well-documented) and these kinds of ideas are clearly follow-up work, so I'll stick to my plan and merge.

I think Ma27 seemed quite negative about this generally, But personally I think just putting the maps inside services.nginx.commonHttpConfig is more than adequate even without RFC-42 nginx (Which I think is basically impossible without introducing some kind of DAG system similar to home-manager)

But I'll be changing my module to match the nixpkgs implementation and work towards upstreaming the autoconfig stuff

In reply to @hexa:lossy.network
synapse will fail to boot when you configure a list of workers where it expects a just a single one, ask me how I know