[Windows] GHCup points to wrong store directory when removing GHC

[jasagredo]

Removing a GHC shows the following message:

[ Info  ] Removing ghc-x.y.z symlinks
[ Info  ] Removing/rewiring ghc-x.y symlinks
[ Info  ] Removing files safely from: C:\ghcup\ghc\9.4.8
[ Info  ] After removing GHC you might also want to clean up your cabal store at: C:\Users\Javier\AppData\Roaming\cabal\store\ghc-9.4.8
Success
Press enter to continue

However that directory is wrong. It should point to C:\Users\Javier\AppData\Local\cabal\store\ghc-9.4.8.

This seems to be caused by readConfig from cabal-install-parsers, which does:

resolveConfig :: Config Maybe -> IO (Config Identity)
resolveConfig cfg = do
    c <- findCabalDir
    return cfg
        { ...
        , cfgStoreDir        = Identity $ fromMaybe (c </> "store")    (cfgStoreDir cfg)
        }

Which is wrong for the default directories on Windows. For the record, this is what the directories look like:

➜ ls ~/AppData/{Local/cabal,Roaming/cabal}
/c/Users/Javier/AppData/Local/cabal:
logs  script-builds  store

/c/Users/Javier/AppData/Roaming/cabal:
bin  config  logs  packages

And this is my cabal config file, only the fields that are not commented:

repository hackage.haskell.org
  url: http://hackage.haskell.org/
remote-repo-cache: C:\Users\Javier\AppData\Roaming\cabal\packages
extra-include-dirs: C:\msys64\clang64\include
extra-lib-dirs: C:\msys64\clang64\lib
extra-prog-path: C:\ghcup\bin,
                 C:\Users\Javier\AppData\Roaming\cabal\bin,
                 C:\msys64\clang64\bin,
                 C:\msys64\usr\bin
build-summary: C:\Users\Javier\AppData\Roaming\cabal\logs\build.log
remote-build-reporting: none
jobs: $ncpus
installdir: C:\Users\Javier\AppData\Roaming\cabal\bin
haddock
init
install-dirs user
install-dirs global
program-locations
program-default-options
  ghc-options: -optc-Wno-pragma-pack -optc-Wno-macro-redefined -optc-Wno-missing-declarations

[hasufell]

So it's a bug in cabal-install-parsers then?

[jasagredo]

It seems like that, yeah. GHCup could do some workaround over it or shall I upstream the issue?

[hasufell]

Best we fix it upstream.

[jasagredo]

Ah I think this issue summarizes the situation upstream. haskell-CI/haskell-ci#655. What remains then for GHCup is whether to use something different of live with this feature/bug.