Use the latest cabal spec in the interactive package init

[Kleidukos]

See #8977

This PR updates the version of the Cabal spec that is suggested by default to users when initialising a project interactively. We now use the latest version (3.4).

QA Notes

Initialising a project with cabal init should prompt the user to use the 3.4 spec by default instead of the 3.0.

---

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.
• Include manual QA notes if your PR relates to cabal-install.

Bonus points for added automated tests!

[andreabedini]

Just a nitpick, cabal init initialises a package, not a project ☺️ also 👍

[ulysses4ever]

I'm confused: is it latest or 3.4? Or are they the same somehow? Non-interactive already does the right thing, i think, so just reuse maybe?

[Kleidukos]

latest and 3.4 are the same from what I see

[ulysses4ever]

It'd still be better to default to the current version of cabal-install imo. Also, it's weird that interactive and non interactive don't do the same.

[ulysses4ever]

One reason why I think it's better to explicitly set latest is because one day 3.4 will no longer be the latest and then we'll have to decide what to do with the version again (e.g. when to bump it). The whole point of setting it to latest always (as discussed in #8616) is that it allows us to avoid this unnecessary decision process.

[ulysses4ever]

@gbaz suggests that we lag one version behind the latest. @fgaz notices that as soon as Cabal spec version is an Enum and Bounded, it should be as simple as to change the default to pred maxBound (instead of the current version, which hard-codes 3.4 or whatever it hard-codes).

This ideally balances my desire to forget about maintenance of this constant forever and some caution about latest being too new for some users.

[ulysses4ever]

Also, let's make sure that -i and -n default to the same thing.

[gbaz]

The broader issue I note is that we haven't updated the init parser to even display or parse or let people choose cabal spec versions 3.6 or 3.8.

In general it seems that when we bump the spec, we forget to also fix the init system -- maybe there's a way to drive init directly off the datatype so this is less possible?

[Mikolaj]

@Kleidukos: what's the best course of action with this one? Open new tickets for all the related proposals and merge this one as is or re-evaluate and perhaps fit more into a single PR (in which case, please mark this a draft and remove the needs-review label)?

[ulysses4ever]

@Kleidukos any news here? I'd be happier if defaultCabalVersion wasn't hardcoded as it's now and was simply pred maxBound (or pred $ pred maxBound). But the current version is an obvious improvement, I think.

[ulysses4ever]

This comment looks like it's doomed to fall behind. Why don't we kill it, and anyone should be able to look up the definition of defautCabalVersion themselves?

[ulysses4ever]

@mergify rebase

[mergify]

rebase

☑️ Nothing to do

• -conflict [📌 rebase requirement]
• -closed [📌 rebase requirement]

[ulysses4ever]

@mergify refresh

[mergify]

refresh

✅ Pull request refreshed

[ulysses4ever]

On a cabal meeting, we discussed that a more flexible policy may be needed to ensure smooth coordination with HLS, see #10457