Repository navigation
Set Cabal version to 3.0 when set notation is used in tested-with field #577
Description
Cabal >= 3.0 allows set notation in the tested-with field, such as
tested-with: GHC == { 8.6.3, 8.4.4, 8.2.2, 8.0.2, 7.10.3, 7.8.4, 7.6.3, 7.4.2 }When we use set notation in the tested-with field in package.yaml, the field is copied to the .cabal file, but the cabal-version is not set to >= 3.0 as needed. This results in the following error when we try to cabal build using the generated cabal file:
unexpected version set syntax used. To use this syntax the package needs to specify at least 'cabal-version: 3.0'. Alternatively, if broader compatibility is important then use a series of single version constraints joined with the || operator: ==8.6.3 || ==8.4.4 || ==8.2.2 || ==8.0.2 || ==7.10.3 || ==7.8.4 || ==7.6.3 || ==7.4.2
20 | tested-with:
21 | GHC == { 8.6.3, 8.4.4, 8.2.2, 8.0.2, 7.10.3, 7.8.4, 7.6.3, 7.4.2 }
| ^ ^
Activity
sol commentedon Apr 20, 2024
There are two things here:
hpackaccept.hpackrender it.Regarding (1), should
hpackaccept something like:Regarding (2), we could still always render this as
tested-with: GHC == 8.6.3, GHC == 8.4.4, ...for maximum compatibility. Or is there a reason not to?Finally, for your original request, when
tested-withis given as a string, then I'm not eager to look at it and pass it through transparently. In that case it would be the responsibility of the user to adjust thecabal-versionas needed.pgujjula commentedon Apr 22, 2024
Regarding (1), that seems reasonable to me to accept. Regarding (2), that also seems like a reasonable way to render it. It also makes sense to just pass through
tested-withtransparently when it's passed as a string.Also, as I think about it more, I think the current option of writing
seems like an acceptable workaround (though a little less aesthetically pleasing).
sol commentedon Jul 26, 2024
PRs welcome.