Fix nix config option

[cbclemmer]

Closes #8452
I did not create a test for the config files when I made #8054. This should test config files for leaving out nix, "nix: True", and "nix: False".
This also adds a line in the --help output for the nix option, it may not be necessary and can be easily removed if it is not needed.

@mhwombat it would be useful for you to confirm that this fix removes the error you were seeing
@Mikolaj I assigned you to review, if this isn't correct, please redirect the review.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[cbclemmer]

But uh... let me get the tests passing firsts

[cbclemmer]

It looks like this pr for bytestring is causing the tests to fail. It looks like the test that failed depended upon getting the latest version of bytestring and then building it, it then tried to build the data-array-byte package but couldn't find it. I'm getting the same results locally when running the test command but I can build the bytestring repo locally just fine. Maybe this is an issue with the server caching packages or something? @Mikolaj What do you think?

[cbclemmer]

Relevant links:
https://github.com/haskell/cabal/blob/master/cabal-testsuite/PackageTests/postCheckoutCommand/cabal.positive.project
haskell/bytestring#410
https://github.com/Bodigrim/data-array-byte

[cbclemmer]

@Mikolaj Tests are passing 🎉

[Mikolaj]

@cbclemmer: thank you for the diagnosis of the spurious CI failure. Indeed that seems to have been the problem and we have since fixed it after a lot of confusion. A pity I haven't looked at this PR earlier. :)

@mhwombat, might we solicit your review? Even just an absent-minded look at the code, a checkout, a run and a report in a comment that it works fine now? I will have a closer look now, but another pair of eyes is very welcome (and also we formally require two reviews for each PR).

[Mikolaj]

Thanks a lot for the fix, the test and the changelog.

[Mikolaj]

Could this trivially be expressed using trueArg or boolOpt or similar? If not trivially, the extra maybeStringToBoolFlag function is fine.

[cbclemmer]

@Mikolaj That part is to make the nix: True|False part work in the config file. The issue was that only enable-nix and disable-nix worked for both the command line arg and the config file. This makes it so that all three work while showing the correct help text. I tried a few different things and none of them satisfied all the things I wanted to do.

[Mikolaj]

Makes sense. I'm just asking about a technicality: optArg' is rather low level, while trueArg or boolOpt may implement some or all of the functionality in maybeStringToBoolFlag, so perhaps they are the better functions to use here?

[cbclemmer]

I can't remember exactly why I didn't go with it, but I'll try again and let you know

[cbclemmer]

@Mikolaj looked at it again and this is what I found:
boolOpt creates two separate help text fields with the only difference being that "enable" or "disable" is prepended to the help text. This is what the original pr was addressing because that was what was being used there and creating bad help text.

trueArg|falseArg I can use this in conjunction with boolOpt to get the help text to work but they end up overriding each other in practice and the tests fail.

optArg is actually a more verbose version of optArg' so it saves characters and complexity to use optArg' over optArg (I assume this is why optArg' is used so much more in general)

[Mikolaj]

Thank you for the analysis. TIL. Once a second review arrives, let's ship it!

[Mikolaj]

The CI failure is probably caused by https://bugs.launchpad.net/ubuntu/+source/git/+bug/1993586 (and by us using the latest Ubuntu container).

[Mikolaj]

May be fixed in #8546 (if CI passes there).

[Mikolaj]

The CI fix seems to work. Let me rebase on it...

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[cbclemmer]

@Mikolaj Thank you, I was really confused

[Mikolaj]

This time it seems it failed due to some corruption, hanging and cancellation after 360min. I'm restarting.

[Mikolaj]

Succes. Quick, @cbclemmer, set one of the merge_me labels to merge the PR while it still passes CI. :)

[Mikolaj]

Edit: with mergify waiting 2 days after the label is set, as per the process.