Make NixStyleOptions

[phadej]

cc @m-renaud

[m-renaud]

Oh geeze, I'm pretty sure in the previous PR we were talking past each other about refactorings and completely different levels of the control flow 😝 I wasn't trying to make any changes to the "command" options/registration/invocation themselves, I was cleaning up the internal implementation details so that we could separate out the lib-only logic (see #6746 for a start).

[m-renaud]

Overall LGTM!

High level comment on naming: the use of "NixStyle" in the name of the options seems overfitted to the original motivation for the v2- style commands. There's nothing "nix" specific about these commands, these are just the options for the v2/new style commends which are now the default, if anything I would name these just simply CommandOptions and CommandFlags and any types related to the old-style commands (if they overlap/conflict) could be renamed to something like LegacyOptions / LegacyFlags. As a concrete example, CmdHaddock now references something with Nix in the name that is unrelated to Nix integration, which I can easily see leading to confusion.

I think this is inline with your #6105 as well, but reduces confusion for anyone looking at the codebase as opposed to the docs.

[phadej]

The #6150 is undecided, yet my impression is that using nix-style local builds is what has most consensus on.

I'd avoid Legacy or any kind of old/new - relative i.e. non absolute - names. We have already Legacy and project config, and it's not related to v1 stuff AFAICT.

For that reason I don't like CommandFlags, as we still have v1- stuff pretty strongly in the codebase. We disagree on documentation already, but in code I'd strongly prefer to rather be explicit than rely on implicit "whatever is default now".

[m-renaud]

Eh fair enough, I'm a -1 personally on "Nix style" but I'll leave my 2c on the other thread. This change is a big improvement over the tuple manipulation that was there before so lets leave any name bikeshedding until afterwards.