Why doesn't stack (installed by ghcup) find msys (installed by ghcup) on Windows - haskell-stack

Question

On my Windows 10 system, I set up Haskell using GHCup. I installed ghc, cabal and stack. Now I am trying to install a package depending on network. Network needs msys for building, but it is obviously not detected:
C:\Users\Michael\source\repos\dummy>stack install network
network> configure
network> [1 of 2] Compiling Main ( C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\Setup.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\Main.o )
network> [2 of 2] Compiling StackSetupShim ( C:\Users\Michael\AppData\Roaming\stack\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\StackSetupShim.o )
network> Linking C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\setup.exe ...
network> Configuring network-3.1.1.1...
network> setup.EXE: The package has a './configure' script. If you are on Windows, This
network> requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
network> are not on Windows, ensure that an 'sh' command is discoverable in your path.
network>
Although documentation seems sparse on it ("you might want to look into extra-path"), I configured stack seemingly correct to have the Shell provided by MSys2 in the path:
C:\Users\Michael\source\repos\dummy>type c:\Users\Michael\AppData\Roaming\stack\config.yaml
templates:
params: null
system-ghc: true
install-ghc: false
skip-msys: true
extra-path:
- 'C:\ghcup\msys64\usr\bin'
- 'C:\ghcup\msys64\mingw64\bin'
extra-include-dirs:
- 'C:\ghcup\msys64\mingw64\include'
extra-lib-dirs:
- 'C:\ghcup\msys64\mingw64\lib'
The MingW path is correct. A more direct test of stack shows that the path isn't applied:
C:\Users\Michael\source\repos\dummy>stack exec sh
Executable named sh not found on path: [".","C:\\Users\\Michael\\source\\repos\\dummy\\.stack-work\\install\\38482417\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\snapshots\\6c93f868\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\compiler-tools\\x86_64-windows\\ghc-8.10.7\\bin","C:\\ghcup\\bin",...,"C:\\WINDOWS\\system32","C:\\WINDOWS","C:\\WINDOWS\\System32\\Wbem","C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\",...,"C:\\Program Files\\Git\\cmd",...,"C:\\ghcup\\bin"]
I redacted parts of the path output that are unrelated to the problem. Obviously, no mention of the MSys directory here. Also obviously, sh.exe is not found, although it is where I expect it:
C:\Users\Michael\source\repos\xilinx>dir c:\ghcup\msys64\usr\bin\sh.exe
Datenträger in Laufwerk C: ist Windows
Volumeseriennummer: xxxx-xxxx
Verzeichnis von c:\ghcup\msys64\usr\bin
19.05.2021 07:47 2.201.842 sh.exe
1 Datei(en), 2.201.842 Bytes
0 Verzeichnis(se), ??.???.???.??? Bytes frei

Answer 1

This is a known issue with Stack. In windows, environt variable names are case-insensitive, but the base library "rio" used by stack doesn't ignore case when looking up environment variables. Under certain circumstances, the program path environment variable is called Path, not PATH. This is the case on the system the issue was observed on:
C:\Users\Michael\source\repos\dummy>set | findstr /i path
HOMEPATH=\Users\Michael
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;...;C:\ghcup\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
In this case, stack fails to expand the PATH variable, so the correct extra-path entries in config.yaml are ignored.
To fix the problem, use the windows environment variables dialog to adjust the spelling of the systemwide path variable. The spelling of the per-user path variable doesn't matter, as the system path is applied first, and merging the user path entries into that variable keeps the spelling set up by applying the system path.