How should a package represent the fact that it does not support a particular GHC version? about cabal

[michaelpj]

I do think a solution that allowed for a user-supplied message would be nice. "Package not buildable in this environment, assertion failed: impl (ghc >= 7.0 && < 8.0)" is better, but "... 'foo does not support GHC 8.0 yet, see $link'" would be even better.

I also think it might be nice to allow this at the top-level somehow. It's usually the case that this stuff is all-or-nothing for a package.

[philderbeast]

For dealing with project P having package K compiling (or not) with GHC X, we're able to have per-GHC, P_x projects¹ (that exclude K if it doesn't build with X). Having per-GHC packages, K_x is unconventional (but actually doable², if not in the same directory) but that got me thinking is there another option?

4. Effectively embed multiple package configurations, each a K for X, in the one package by using impl(ghc) at the top-level.

Footnotes

1. Updo does this and uses a ghc-x.y.z.* naming convention for its ghc-prefixed-targets ↩

2. I haven't done this! I think it would be possible with hpack-dhall having done something similar varying packaging with sub-library granularity. Compare plugin-for-blobs/package.dhall that puts everything in one package to the other **/package.dhall that create smaller packages. The reused configuration is in *.package-relative.dhall files (dhall functions), such as plugin-for-blobs/uom/quantity/package-relative.dhall, that get imported and called. ↩

[michaelpj]

Projects only work if everything is in one repository. I want this to work even with published packages in a package repository like Hackage.

[philderbeast]

Projects only work if everything is in one repository.

Projects using source-repository-package can work off-repository, can't they? I wonder if there's a cabal-testsuite/PackageTests test for that?

[alt-romes]

I agree that this would be useful, and the buildable approach sounds good to me.

In #3072 is suggested an assert: field with which the author also suggests we could assert a ghc version is within some bounds:

assert: impl(ghc >= 7.0 && < 8.0)

Coupled with good error messages printing the assertion, perhaps it would bring the resolution you seek without having to drop into the buildable "low-level" detail.

[andreabedini]

I believe adding a message to buildable: false (or equivalent) is the right way to do it.

If anybody wants to work on this I can advise/mentor.

[gbaz]

I agree. I think that we should just start by attaching a message to buildable: false constraints that morally works like "imprecise exceptions" and the message is derived from the surrounding conditional clause (if any) that guards the flag.