use rfc42 for nginx virtualhosts

[teto]

Issue description

I've had to get into nginx setup for a personal website, past the copy/paste nixos wiki thing.

1. A first comment is that the nginx checks (apparently nginx -t) is run as part of a PreExec step of the systemd unit. I wonder if it oculd be made a checkInstallPhase ? (naive question maybe). Asking because I find issues after deploying my server and I would rather find them earlier during the build
2. The submodule for virtualhost doesn't use rfc42 ("freeform" settings) so for instance proxy_pass becomes proxyPass in nixpkgs. I like the one-to-one mapping allowed by freeform settings so I wanted to propose that conversion. It makes nixpkgs less intimidating and you can grep proxy_pass in nixpkgs with less prior knowledge about it.

[hacscred]

RFC42 just gives guidelines. Your issue is really too unspecific to not result in a huge amount of discussion.

I would either like to see a concrete design for nginx specifically and not just for one option accompanied by a prototype to see that people are serious about it.

Closing this issue and creating a new one over the period of some weeks would probably lead to better results.

For example, you are saying you want to use a different style of variables, but all of that needs backwards compatibility. An approach like the out if tree simple NixOS mail server, which can develop and prove itself out of tree until someday it's the one "everyone" wants to use is much more productive. If, at some point, your simpleNginx module proves to be superior, then it could just be a PR.

If you want to keep it open, instead use it as a way to find collaboration or something like that and close it after six months.

[Ma27]

I think the problem here is that nginx configuration is pretty powerful and I'm not sure if we can push it into an RFC42-like format. For instance, how would you model

• if clauses
• arbitrarily many arguments (including, but not only named arguments - for instance proxy_cache_path path [levels=levels] ...)
• ordering (yes, we already have priority for locations, but I'm pretty sure there are far more ordering-sensitive constructs and when migrating an existing sufficiently complex config to an rfc42 config, you'll have to carefully add priority to ~everything or hunt subtle behavior changes for the next few months).

Regarding proxyPass: if you search for proxy_pass in the option search, you'll immediately see that proxyPass is the relevant option in our module system and in my experience, that's the way beginners are looking for options anyways.

[teto]

For example, you are saying you want to use a different style of variables, but all of that needs backwards compatibility.

I used lib.mkAliasOptionModuleMD or mkRenamedOptionModule for that. That's what I used when migrating sshd.

Your issue is really too unspecific to not result in a huge amount of discussion.

Maybe I am wrong because I dont know nginx much but in my experience across various modules, the freeform settings was a no-brainer:

1. rename the options so that they fit the program name and not a nixpkgs made up name
2. add the mkRenamedOptionModule for backwards compatibility and voila

It can be done iteratively without having to change the full nginx module. My suggestion scoped it to the "location" part for instance.

For instance, how would you model ...

same as currently. You dont have to remove the current options, just rename them and keep the hardcoded option if it's needed later. And the module already has extraConfig for everything that can not be translated by nix.

[Ma27]

same as currently. You dont have to remove the current options, just rename them and keep the hardcoded option if it's needed later. And the module already has extraConfig for everything that can not be translated by nix.

The reason I brought this up is because one of the core ideas of RFC42 is to get rid of extraConfig options which is not applicable here.