Don't warn on mhs-options (fixes #11341)

[sol]

This addresses #11341.

---

Template Α: This PR modifies behaviour or interface

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.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[geekosaur]

You should have used the template and filled in the appropriate checklist.

[ulysses4ever]

Yes. I'd be great if you could restore the template by copying it from some other pr. This probably needs a changelog at least.

[sol]

@ulysses4ever I already added a changelog entry. I think the other things from the list did not apply.

I'll keep the template in the future and tick the things that apply.

[sol]

Do I need to take any action regarding the failing Windows binary release build (zip: command not found)?

[ulysses4ever]

@sol no. Sorry for the confusion.

[geekosaur]

You know, I think we might need a Hackage maintainer to rule on whether this actually needs to be a file format change, since it impacts what Hackage accepts. @phadej?

[mergify]

Merge Queue Status

🚫 The pull request has left the queue (rule: default) at ec10df6

This pull request spent 1 hour 23 minutes 43 seconds in the queue, including 1 hour 13 minutes 8 seconds running CI.
The checks were run on draft #11348.

Required conditions to merge

• any of [🛡 GitHub branch protection]:
  • check-neutral = Validate post job
  • check-skipped = Validate post job
  • check-success = Validate post job
• #approved-reviews-by >= 2 [🛡 GitHub branch protection]
  • Don't warn on mhs-options (fixes #11341) #11344
• #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
  • Don't warn on mhs-options (fixes #11341) #11344
• #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • Don't warn on mhs-options (fixes #11341) #11344
• any of [🛡 GitHub branch protection]:
  • check-success = Doctest Cabal
  • check-neutral = Doctest Cabal
  • check-skipped = Doctest Cabal
• any of [🛡 GitHub branch protection]:
  • check-success = Meta checks
  • check-neutral = Meta checks
  • check-skipped = Meta checks
• any of [🛡 GitHub branch protection]:
  • check-success = docs/readthedocs.org:cabal
  • check-neutral = docs/readthedocs.org:cabal
  • check-skipped = docs/readthedocs.org:cabal
• any of [🛡 GitHub branch protection]:
  • check-success = fourmolu
  • check-neutral = fourmolu
  • check-skipped = fourmolu
• any of [🛡 GitHub branch protection]:
  • check-success = hlint
  • check-neutral = hlint
  • check-skipped = hlint
• any of [🛡 GitHub branch protection]:
  • check-success = Bootstrap post job
  • check-neutral = Bootstrap post job
  • check-skipped = Bootstrap post job
• any of [🛡 GitHub branch protection]:
  • check-success = whitespace
  • check-neutral = whitespace
  • check-skipped = whitespace
• any of [🛡 GitHub branch protection]:
  • check-success = Check sdist post job
  • check-neutral = Check sdist post job
  • check-skipped = Check sdist post job
• any of [🛡 GitHub branch protection]:
  • check-success = Changelogs
  • check-neutral = Changelogs
  • check-skipped = Changelogs

Reason

The merge conditions cannot be satisfied due to failing checks

Failing checks:

• ❌ Validate post job

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[geekosaur]

@Mergifyio rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Mikolaj]

You know, I think we might need a Hackage maintainer to rule on whether this actually needs to be a file format change, since it impacts what Hackage accepts. @phadej?

In that case, let's wait with the merging. @gbaz: what do you think?

[Mikolaj]

Let's wait until hackage-server maintainers recommend whether this should be a file format change. BTW, where do I look up who the maintainers are?

[Mikolaj]

@mpickering: from your long cabal dev experience, would you have any advice about this one?

[ffaf1]

Gershom (on Matrix) confirms that this should not impact Hackage.
He points to x-fields as an option, but I understand this might not palatable to MicroHs developers.

[Mikolaj]

Gershom (on Matrix) confirms that this should not impact Hackage.

@ffaf1: As in "as implemented this will not impact" or "it will impact even though it should not"?

[Mikolaj]

Oh, OK, never mind, I've re-read it in the cabal Matrix room and it says "it will not impact", so I'm unblocking the merging. Gershom said "imho none of this impacts hackage. my main comment is cabal supports not warning about x-fields already i believe? so mhs can just use x-fields now and forgo solving any of this or needing any patch until later" and also "x-fields are there because they’re fields cabal doesn’t know how to use. if they teach cabal to use mhs-options then they should add a field. the prefix means “cabal-the-tool ignores this” which is the case", though the whole discussion is worth a read (unfortunately, it's above the blob of spam we recently received).

@sol: I'm unblocking the merge, but I'm removing the merge label until you can read the discussion at your leisure and decide whether an x-field is a good alternative for your use case. If not, please kindly set the merge label again.

Confirmed this is not a blocker.

[geekosaur]

Sigh. So the answer to my question is that this does inpact Hackage… because Hackage uses cabal to validate cabal files, meaning that a cabal that only considers GHC a first class compiler is a gatekeeper for Hackage that keeps it GHC-only in practice.