Add with-compiler to snapshot's cabal.config file

[andreabedini]

This patch adds the specification of what compiler to use for a snapshot using cabal's "with-compiler" option.

Context

cabal-install 3.8 has gained the ability of using remote imports in cabal project files (https://cabal.readthedocs.io/en/latest/cabal-project.html#conditionals-and-imports). This was done as a first attempt to support using stackage snapshots directly with cabal (see https://github.com/haskell/cabal/issues/7556 for a discussion of the problem).

In short, one can create a cabal.project file as follows

-- this is the default if no cabal.project file exists
packages: ./*.cabal

-- this is needed at the moment and is the subject of this PR
with-compiler: ghc-9.0.2

-- this is the new bit
import: https://www.stackage.org/lts-19.10/cabal.config

and cabal use the package versions specified by lts-19.10. To reproduce the stackage snapshot (modulo revisions, see note below), one has to use the same compiler as the snapshot, therefore I believe it's important to add the with-compiler flag above.

This PR adds the with-compiler line to the cabal.config files as generated by stackage-server. Shortening the boilerplate down to:

packages: ./*.cabal
import: https://www.stackage.org/lts-19.10/cabal.config

Notes

• Users have been able to grab the lts cabal.config and feed it to cabal as cabal.project.freeze for a long time. What's next is just the convenience of pointing directly to stackage.
• As it stands, cabal.config fixes the package versions but not the package cabal file revisions. I am aware of the difference and this PR does not improve on that regard.
• A stackage snapshot also fixes package flags, which should be also reflected in the cabal.config file. I haven't implemented this yet.
• This might not be the definite answer to the question "how to use stackage snapshots with cabal" and does not aim to replicate stack's workflow with cabal. The aim of this PR is to (incrementally) improve interoperability between different tools.

[bergmark]

-- this is the new bit
import: https://www.stackage.org/lts-19.10/cabal.config

This doesn't need to affect this PR, but I have a couple of questions on the import feature:

• Are the imports cached locally?
• Since these configs are mutable, can I specify a checksum?

[andreabedini]

Great questions.

Are the imports cached locally?

Yes, they are. cabal as a general caching strategy built into the http transport, which uses the if-modified-since header and etags (refrence). The file is stored on disk in the dist-newstyle directory.

❯ cabal build --dry-run -v
Project settings changed, reconfiguring...
creating /home/andrea/tmp/dist-newstyle/cache
Running: /usr/bin/curl 'https://www.stackage.org/lts-19.10/cabal.config' --output '/home/andrea/tmp/dist-newstyle/src/https:__www.stackage.org_lts-19.10_cabal24187-0.config' --location --write-out '%{http_code}' --user-agent 'cabal-install/3.8.0.20220526 (linux; x86_64)' --silent --show-error --dump-header /home/andrea/tmp/dist-newstyle/src/curl-headers24187-1.txt
Downloaded to
/home/andrea/tmp/dist-newstyle/src/https:__www.stackage.org_lts-19.10_cabal.config
creating /home/andrea/tmp/dist-newstyle
creating /home/andrea/tmp/dist-newstyle/cache
this build was affected by the following (project) config files:
- /home/andrea/tmp/cabal.project
- https://www.stackage.org/lts-19.10/cabal.config
Up to date

Since these configs are mutable, can I specify a checksum?

Not at the moment but this sounds like a feature worth opening an issue about. I'll do that some time today.

On a slight tangent the message Please append these contents to the end of your global cabal config file. To only use tested packages, uncomment the following line and comment out other remote-repo lines might need some love because cabal doesn't seem to accept that remote-repo option anymore. I'd be happy to sort it out but I am not sure of the intention behind the message.

[snoyberg]

This is now deployed live.

[andreabedini]

@snoyberg thank you for the quick turnaround! @bergmark https://github.com/haskell/cabal/issues/8204