Does cabal-3.10 impose `setup.Cabal < 3.12`?

[andreasabel]

When trying to make cabal-3.10 build packages with custom setups on GHC 9.10.0 (alpha3), which ships with Cabal-3.12, cabal insists to build Cabal-3.10.3.0.
If I try to force using the installed Cabal, constraint solving fails.

system-filepath-0.4.14$ cabal build -w ghc-9.10.0 -c 'setup.Cabal >=3.12'
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: system-filepath-0.4.14 (user goal)
[__1] next goal: system-filepath:setup.Cabal (dependency of system-filepath)
[__1] rejecting: system-filepath:setup.Cabal-3.12.0.0/installed-c30b
(constraint from maximum version of Cabal used by Setup.hs requires <3.12)

The package itself does not impose an upper bound on Cabal:

custom-setup
  setup-depends: Cabal >= 1.8, base >=4.0 && <5

This is not a problem with cabal-3.11 (master), this one does not impose this upper bound.

The docs say (https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-custom-setup-setup-depends):

If the field is not specified the implicit package set will be used. The package set contains packages bundled with GHC (i.e. base, bytestring) and specifically Cabal. The specific bounds are put on Cabal dependency: lower-bound is inferred from cabal-version, and the upper-bound is < 1.25.

(Ok, the "< 1.25" is definitively stale doc here.)
The docs seem to say that the upper bound comes from whatever is bundled with GHC, which should be including Cabal-3.12 (bundled with GHC 9.10 alpha3).

[andreasabel]

Ruining my CIs...: https://github.com/BNFC/bnfc/actions/runs/8800309303/job/24151220023#step:15:28

[andreasabel]

@ffaf1: This issue prevents me from evaluating Cabal-3.12 with a released cabal-install, and the following one with master:

• Wrong condition for passing --working-dir flag #9940

Not sure how I should verify relaxations to Cabal < 3.13 in my projects now...

[Bodigrim]

This is expected behavior:

cabal/cabal-install/src/Distribution/Client/ProjectPlanning.hs

Lines 1397 to 1414 in bccc59f

	-- As we can't predict the future, we also place a global upper
	-- bound on the lib:Cabal version we know how to interact with:
	--
	-- The upper bound is computed by incrementing the current major
	-- version twice in order to allow for the current version, as
	-- well as the next adjacent major version (one of which will not
	-- be released, as only "even major" versions of Cabal are
	-- released to Hackage or bundled with proper GHC releases).
	--
	-- For instance, if the current version of cabal-install is an odd
	-- development version, e.g. Cabal-2.1.0.0, then we impose an
	-- upper bound `setup.Cabal < 2.3`; if `cabal-install` is on a
	-- stable/release even version, e.g. Cabal-2.2.1.0, the upper
	-- bound is `setup.Cabal < 2.4`. This gives us enough flexibility
	-- when dealing with development snapshots of Cabal and cabal-install.
	--
	setupMaxCabalVersionConstraint =
	alterVersion (take 2) $ incVersion 1 $ incVersion 1 cabalVersion

[andreasabel]

Thanks for digging this out @Bodigrim!

Maybe one should not have search through the source code of cabal to get this information.

1. The docs (see OP) need to mention this.

2. The reason for the constraint should be clearer. Currently it says:

   (constraint from maximum version of Cabal used by Setup.hs requires <3.12)

   Better formulation:

   (the use of cabal 3.10.* limits the maximum version of Cabal used by Setup.hs to <3.12)

I am also a bit skeptical about placing this limit in the first place.

As we can't predict the future, we also place a global upper bound on the lib:Cabal version we know how to interact with

This sound to me like:

As I cannot predict whether my house will stand for 50 years, I will tear it down after 20 years.

I do not see the point of forcing pessimism into the constraint solving here.
Should things actually break with a too new Cabal, then I can always place a suitable upper bound with -c setup.Cabal < VERSION, or can't I?

[Bodigrim]

I am also a bit skeptical about placing this limit in the first place.

Given that Cabal-X is usually released a few weeks earlier than cabal-install-X, the limitation is quite annoying.

Could it be "current version + 4"? So that cabal-install-3.10 could be used to test Cabal-3.12, hoping that cabal-install-3.12 will be available in time for Cabal-3.14.

[andreasabel]

The original issue seems to be:

• cabal-install should warn if using a version of ghc that is newer than it knows about #415

However this issue only speaks about warnings which I find totally appropriate.
So we would want a warning if cabal-x builds Setup.hs with Cabal-y where y is a release version bigger than x rather than a hard constraint one cannot overwrite.

The commit that introduced the OP is c92b715. It has no tests and no doc changes may thus be simply revertible.