Choco install of cabal 3.2 fails in connection with ghc 9.6.1

[andreasabel]

Lifted from:

• Support GHC 9.6.1 Mistuke/GhcChoco#20 (comment)

cabal-3.2.0.0 seemingly cannot be installed by chocolatey in connection with ghc-9.6.1:
https://github.com/haskell/actions/actions/runs/4398118597/jobs/7704243235#step:3:121
It works with other GHC versions.
Run with more debug info: https://github.com/haskell/actions/actions/runs/4398118597/jobs/7704278660#step:3:2234

@Mistuke writes:

The GHCs have a dependency on cabal they're expected to work with. In this case installing 9.6.1 installs cabal 3.10.1 as well and configures it. [...] the config file created by 3.10.1 cannot be read by 3.2 and so it fails. [...] it's failing while updating the config file.
[...] you can install ghc with --ignore-dependencies to not install the new cabal.
[...] the update fails after 3.10.1 creates the config:

cabal.exe: Error parsing config file C:\cabal\config:24:
Parse of field 'nix' failed (<viewAsFieldDescr>disable): disable

[...] 3.2 and 3.10 cannot coexist

[Bodigrim]

On Windows GHC 9.4+ mandates Cabal 3.8+ for correct linking, so I’d say this is more of an accidental feature than a bug.

[Mistuke]

Agreed, I thought that in general new major releases of ghc always need a new cabal. But I wasn't sure so didn't mention it earlier :)

[andreasabel]

In #204 I switch off the unlucky triple Windows/ghc-9.6/cabal-3.2 and in general pair ghcs with their matching cabal.
Question is whether the setup action should check for valid triples (maybe another case of over-engineering) or whether the README should warn about mismatches.

[andreasabel]

@Mistuke: In the CI https://github.com/haskell/actions/actions/runs/4402374805/jobs/7709470944 for PR #204 any attempt to install cabal<3.10 on Windows fails. Well except for this run https://github.com/haskell/actions/actions/runs/4402374805/jobs/7709471152 where just the use of cabal fails with a parsing error on the nix field.
Image is 2023-03-07 (https://github.com/haskell/actions/actions/runs/4402374805/jobs/7709470944#step:1:9).

Weird, because yesterday something still worked on the same image: https://github.com/haskell/actions/actions/runs/4399819678/jobs/7704611067

[Mistuke]

Do you cache the folder with the cabal config in it by chance?

[andreasabel]

Don't think so. The only caching mentioned is for npm:

actions/.github/workflows/workflow.yml

Lines 25 to 29 in 132416f

	- uses: actions/setup-node@v3
	with:
	node-version: "16"
	cache: "npm"
	cache-dependency-path: setup/package-lock.json

[Mistuke]

Could you run cabal user-config diff? should show if it was, and try cabal user-config init -f to recreate it. note that this isn't a fix, as it removes the entries for msys2, but just want to see if something got cached.

[Mistuke]

Oh I see the problem.. with cabal 3.10.1 now released the constraints on the GHC packages only have which minimum version they support. So older GHCs are also defaulting to 3.10.1 since it's supposed to be backwards compatible.

So now installing GHC 9.2.7 will also get you cabal 3.10.1.

  C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe choco install ghc --version 9.2.7 -m --no-progress -r
  Installing the same package with multiple versions is deprecated and will be removed in v2.0.0.
  Installing the following packages:
  ghc
  By installing, you accept licenses for the packages.
  
  cabal v3.10.1.0 [Approved]
  cabal package files install completed. Performing other installation steps.
  Downloading cabal 64 bit
    from 'https://downloads.haskell.org/cabal/cabal-install-3.10.1.0/cabal-install-3.10.1.0-x86_64-windows.zip'
  
  Download of cabal-install-3.10.1.0-x86_64-windows.zip (14.91 MB) completed.
  Hashes match.

Since you want specific versions of GHC and cabal your recipe should be this.

choco install chocolatey-core.extension
choco install ghc --version <version> --ignore-dependencies
choco install cabal --version <version>

This will allow you do mix and match as before, and also avoid the need to use the -m flag which will be removed in chocolatey 2.0.0.

It will also be faster as it doesn't reconfigure the package only to replace it.

[Mikolaj]

Is this related to haskell/cabal#8841?

[Mistuke]

no, this is related to cabal 3.10.1 seemingly having added a backwards incompatible change to the global config file format. So when cabal 3.10.1 is used you cannot use any older cabal version again without removing the global config.

[Mistuke]

@andreasabel I have temporarily unlisted cabal 3.10.1 to give you time to change the options to chocolatey and so that it doesn't break the existing actions workflows.

It will still be installed when someone installs GHC 9.6.1, but it won't be default for older ones. Let me know when I can list it again.

[Mikolaj]

In case it's related (unlikely), we had a problem with our cabal CI as well: https://github.com/haskell/cabal/actions/runs/4400882899/jobs/7706599146, probably stemming from the XGD switch:

Setting up cabal
  Adding /home/runner/.cabal/bin to PATH
  /home/runner/.ghcup/bin/cabal update
  Downloading the latest package list from hackage.haskell.org
  Package list of hackage.haskell.org has been updated.
  The index-state is set to 2023-03-13T02:25:22Z.
...
Run actions/cache@v3
...
Config file path source is default config file.
Config file not found: /home/runner/.cabal/config
Writing default configuration to /home/runner/.cabal/config
Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
update' to download it.
Error: cabal: Unknown package "cabal-plan".

and a possible explanation:

it probably does cabal update to an XDG directory
and then it restores GHA cache, which brings back ~/.cabal
and so, to preserve backward compatibility, it switches completely to ~/.cabal
ignoring the result of cabal update
so the fix would be to run cabal update after GHA cache is restored

[Mistuke]

In case it's related (unlikely), we had a problem with our cabal CI as well:

Unlikely, I've unlisted the cabal 3.10.1 package, so existing actions won't pick it up anymore.

[Mistuke]

Just to be completely clear. since the title mentions chocolatey, this is a restriction from cabal.

e.g.

wget https://downloads.haskell.org/~cabal/cabal-install-3.10.1.0/cabal-install-3.10.1.0-x86_64-windows.zip
wget https://downloads.haskell.org/~cabal/cabal-install-3.2.0.0/cabal-install-3.2.0.0-x86_64-unknown-mingw32.zip
mkdir 3.10.1.0 && cd 3.10.1.0 && unzip ../cabal-install-3.10.1.0-x86_64-windows.zip && cd -
mkdir 3.2.0.0 && cd 3.2.0.0 && unzip ../cabal-install-3.2.0.0-x86_64-windows.zip && cd -

PS C:\Users\WDAGUtilityAccount\Downloads> .\3.10.1.0\cabal.exe user-config init
Writing default configuration to
C:\Users\WDAGUtilityAccount\AppData\Roaming\cabal\config
PS C:\Users\WDAGUtilityAccount\Downloads> .\3.2.0.0\cabal.exe update
cabal.exe: Error parsing config file
C:\Users\WDAGUtilityAccount\AppData\Roaming\cabal\config:24:
Parse of field 'nix' failed (<viewAsFieldDescr>disable): disable

So this is cabal. Once you use 3.10.1.0 you can never go back to earlier versions without completely wiping your configuration file. and cabal 3.10.1.0 cannot coexist with any other cabal version.

[Mikolaj]

That's a correct clarification. BTW, is it common that people use the same CI cache for different GHC or cabal versions instead of one cache for each combination? Am I right that with separate caches, this is not a problem (you never go back to pre-3.10 in your cache of 3.10 builds)?

[Mistuke]

previously it wouldn't be much of an issue since inside the cache you had separate folders for different GHC versions.
so as long as you used the right cabal with the right ghc it would still work.

There are two things here:

• the constrains on GHC packages on chocolatey specify only a minor version. so for GHC 9.4.4 it says something like >= cabal 3.8.0.0 under the understanding that cabals > 3.8.0.0 would also work.
• But actions gives users the ability to install a paired cabal, problem is that install ghc 9.4.4 now gets you cabal 3.10.1.0 and they then try to downgrade. The downgrade fails because it can't read the config file.

now the problem can be solved as I mentioned above by telling chocolatey not to install the cabal dependency automatically. this then allows you to install any other cabal version.

So this should be easy to workaround with the instructions I gave in #202 (comment)

But if an end user find a bug now in cabal 3.10, they can't downgrade ghc and cabal without losing their configs. Which is ok, but the changelog for cabal 3.10.1.0 don't mention that this is a one way upgrade.

[gbaz]

So this is cabal. Once you use 3.10.1.0 you can never go back to earlier versions without completely wiping your configuration file. and cabal 3.10.1.0 cannot coexist with any other cabal version.

I think this statement is slightly too strong in a few ways. First, it is "once you user-config init in 3.10.1.0" you cannot go back. (I.e. if you have an existing user config you don't update/overwrite its fine). Second, I think you could simply delete that line and then go back? And finally, I think that therefore a bunch of cabal versions can coexist, including 3.10.1.0, but we just have the constraint that the default config file generated by 3.10.1.0 does not fall in the set of config files that allow such coexistence?

[Mistuke]

So this is cabal. Once you use 3.10.1.0 you can never go back to earlier versions without completely wiping your configuration file. and cabal 3.10.1.0 cannot coexist with any other cabal version.

I think this statement is slightly too strong in a few ways. First, it is "once you user-config init in 3.10.1.0" you cannot go back. (I.e. if you have an existing user config you don't update/overwrite its fine). Second, I think you could simply delete that line and then go back? And finally, I think that therefore a bunch of cabal versions can coexist, including 3.10.1.0, but we just have the constraint that the default config file generated by 3.10.1.0 does not fall in the set of config files that allow such coexistence?

The statement is perfectly correct. For one it has nothing to do with user-config, Just simply using cabal is enough.

PS C:\Users\WDAGUtilityAccount\Downloads> .\3.10.1.0\cabal.exe update
Config file path source is default config file.
Config file not found:
C:\Users\WDAGUtilityAccount\AppData\Roaming\cabal\config
Writing default configuration to
C:\Users\WDAGUtilityAccount\AppData\Roaming\cabal\config
Warning: Caught exception during _mirrors lookup:user error (DnsQuery_A failed
with 14)
Warning: No mirrors found for http://hackage.haskell.org/
Downloading the latest package list from hackage.haskell.org
Package list of hackage.haskell.org has been updated.
The index-state is set to 2023-03-13T16:47:26Z.

PS C:\Users\WDAGUtilityAccount\Downloads> .\3.2.0.0\cabal.exe update
cabal.exe: Error parsing config file
C:\Users\WDAGUtilityAccount\AppData\Roaming\cabal\config:24:
Parse of field 'nix' failed (<viewAsFieldDescr>disable): disable

So trying to nuance it to "if you use user-config" is incorrect. Secondly both chocolatey and ghcup have to configure msys2 in order for Haskell on Windows to be useful for the majority of users. So this is the standard configuration as far as I know.

Third I don't think neither me or ghcup maintainers want to sed config files, that defeats the point of user-config. And the problem here is that we can't even use user-config to remove the line since it doesn't work anymore.

So no, I think the statement that you cannot use 3.10.1.0 and other cabal versions concurrently is perfectly correct. and similarly that once you go to 3.10.1.0 you can't go back without removing the config file, or modifying the config file in such a way that installers can't automate safely.

[andreasabel]

@Mistuke wrote:

Since you want specific versions of GHC and cabal your recipe should be this.

choco install chocolatey-core.extension
choco install ghc --version <version> --ignore-dependencies
choco install cabal --version <version>

This will allow you do mix and match as before, and also avoid the need to use the -m flag which will be removed in chocolatey 2.0.0.

Ok, I can give it a try. --ignore-dependencies sounds a bit dangerous, but if the author of Choco GHC tells me so...

[Mistuke]

@andreasabel well you're overriding the dependencies anyway afterwards 😉

Hmm what may also work is this: install cabal before ghc.

Yeah, just checked, if you install cabal before ghc, as long as the cabal meets the minimum version the constraint solver won't force a new one.

So for instance installing cabal 3.6 and then ghc 9.2.7 won't force a cabal upgrade. This will allow you to keep dependencies.

[Mistuke]

@andreasabel yeah, that's probably what you want, just flip the order of the installs. install cabal before ghc, and as long as you don't violate the constraints (which you shouldn't for a working cabal+ghc) then it'll work fine.

[andreasabel]

@Mistuke : I had already implemented the --ignore-dependencies solution. It is pushed onto the main branch already... (Too late today, maybe I change the fix tomorrow to swapping the installation order.)

Released main branch as v2 and latest, not yet as 2.3.6 or 2.3.

[gbaz]

So no, I think the statement that you cannot use 3.10.1.0 and other cabal versions concurrently is perfectly correct. and similarly that once you go to 3.10.1.0 you can't go back without removing the config file, or modifying the config file in such a way that installers can't automate safely.

Got it! I think I understand the confusion -- and i wasn't trying to minimize the problem, just be clear on scope. I had misread your statement as a general one, and instead you're naturally concerned specifically with automation here, and, in that setting what you're saying makes a lot of sense. I think going forward, cabal should still be able to add/change flags in the config, but it should really try to avoid doing it in a way that has backwards incompat settings written by default.

[Mistuke]

@gbaz aye I'm not arguing that cabal shouldn't be able to make changes. But an unknown field shouldn't be fatal. That older cabals don't recognize the field also means they can't use it so it's irrelevant to them.

[andreasabel]

Implementing @Mistuke's suggestion to install cabal before ghc would amount to swapping the entries in the opts record, which implicitly determines the order of installation:

actions/setup/src/opts.ts

Lines 161 to 187 in 86bd3ed

	const opts: Options = {
	ghc: {
	raw: verInpt.ghc,
	resolved: resolve(
	verInpt.ghc,
	ghc.supported,
	'ghc',
	os,
	ghcEnable // if true: inform user about resolution
	),
	enable: ghcEnable
	},
	ghcup: {
	releaseChannel: ghcupReleaseChannel
	},
	cabal: {
	raw: verInpt.cabal,
	resolved: resolve(
	verInpt.cabal,
	cabal.supported,
	'cabal',
	os,
	cabalEnable // if true: inform user about resolution
	),
	enable: cabalEnable,
	update: cabalUpdate
	},

[andreasabel]

Remaining bit in

• Choco: install cabal before ghc #214