cabal doesn't inherit the path from cabal/config in PowerShell

[jasagredo]

Describe the bug

Cabal config specifies (as configured by GHCup):

extra-include-dirs: C:\msys64\mingw64\include
extra-lib-dirs: C:\msys64\mingw64\lib
extra-prog-path: C:\ghcup\bin,
                 C:\cabal\bin,
                 C:\msys64\mingw64\bin,
                 C:\msys64\usr\bin

And I have this test-suite that depends on external DLLs:

➜ ldd ./dist-newstyle/build/x86_64-windows/ghc-9.6.3/ouroboros-consensus-cardano-0.12.1.0/t/cardano-test/build/cardano-test/cardano-test.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffcf45d0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffcf34c0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffcf1ef0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffcf1da0000)
        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ffcf2770000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffcf1d00000)
        libsodium-26.dll => /mingw64/bin/libsodium-26.dll (0x7ffc37c60000)
        libsecp256k1-0.dll => /mingw64/bin/libsecp256k1-0.dll (0x7ffbf91c0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffcf3650000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffcf3590000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffcf3f50000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffcf2440000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffcf1ec0000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffcf2ff0000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffcf3740000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffcf1b70000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ffcf3d10000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x7ffcc3fa0000)
        ole32.dll => /c/WINDOWS/System32/ole32.dll (0x7ffcf24f0000)
        dbghelp.dll => /c/WINDOWS/SYSTEM32/dbghelp.dll (0x7ffcebaa0000)
        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ffcf3870000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x7ffccef00000)
        combase.dll => /c/Windows/System32/combase.dll (0x1462d380000)
        OLEAUT32.dll => /c/WINDOWS/System32/OLEAUT32.dll (0x7ffcf2690000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffcf1190000)
        WINMM.dll => /c/WINDOWS/SYSTEM32/WINMM.dll (0x7ffce7f50000)
        IPHLPAPI.DLL => /c/WINDOWS/SYSTEM32/IPHLPAPI.DLL (0x7ffcf0370000)
        dbgcore.DLL => /c/WINDOWS/SYSTEM32/dbgcore.DLL (0x7ffcbd580000)

However, when I try to run it the following just aborts with no error message:

PS C:\Users\Javier\code\cardano\ouroboros-consensus> cabal run cardano-test --verbose -- -p "/ExtLedgerState_Conway/"
Warning: C:\cabal\config: Unrecognized stanza on line 33
Project settings changed, reconfiguring...
Warning: C:\cabal\config: Unrecognized stanza on line 33
creating C:\Users\Javier\code\cardano\ouroboros-consensus\dist-newstyle
creating C:\Users\Javier\code\cardano\ouroboros-consensus\dist-newstyle\cache
this build was affected by the following (project) config files:
- ./asserts.cabal
- C:\Users\Javier\code\cardano\ouroboros-consensus\cabal.project
- C:\Users\Javier\code\cardano\ouroboros-consensus\cabal.project.local
creating C:\Users\Javier\code\cardano\ouroboros-consensus\dist-newstyle\build
creating C:\Users\Javier\code\cardano\ouroboros-consensus\dist-newstyle\tmp
Selecting ouroboros-consensus-cardano-0.12.1.0-inplace-cardano-test to supply
cardano-test
Running: "C:\Users\Javier\code\cardano\ouroboros-consensus\dist-newstyle\build\x86_64-windows\ghc-9.6.3\ouroboros-consensus-cardano-0.12.1.0\t\cardano-test\build\cardano-test\cardano-test" "-p" "/ExtLedgerState_Conway/"

It is using C:\cabal\config because if I introduce garbage there I see:

Warning: C:\cabal\config: Unrecognized stanza on line 33
Project settings changed, reconfiguring...
Warning: C:\cabal\config: Unrecognized stanza on line 33

If I manually extend the PATH, it works:

PS C:\Users\Javier\code\cardano\ouroboros-consensus> $env:Path += ';C:\msys64\mingw64\bin'
PS C:\Users\Javier\code\cardano\ouroboros-consensus> cabal run cardano-test -- -p "/ExtLedgerState_Conway/"
cardano
  Golden tests
    SerialiseDisk
      ExtLedgerState
        ExtLedgerState_Conway: OK

All 1 tests passed (0.01s)

Which suggests the pwsh path is not being extended properly.

Expected behavior

I would expect cabal to extend the PATH also on PowerShell.

System information

• MINGW64_NT-10.0-22621
• cabal-install version 3.10.2.0, compiled using version 3.10.2.1 of the Cabal library

Additional context

In MinGW shell it works just fine.

[jasagredo]

Actually even simpler:

PS C:\Users\Javier\code\cardano\ouroboros-consensus> rm -r -fo .\dist-newstyle\
PS C:\Users\Javier\code\cardano\ouroboros-consensus> cabal build cardano-test
Error: cabal-3.10.2.0.exe: The program 'git' is required but it could not be
found.
PS C:\Users\Javier\code\cardano\ouroboros-consensus> $env:Path += ';C:\msys64\usr\bin'
PS C:\Users\Javier\code\cardano\ouroboros-consensus> cabal build cardano-test
Cloning into '/c/Users/Javier/code/cardano/ouroboros-consensus/dist-newstyle/src/cardano-l_-118cb9e4f6caae19'...
remote: Enumerating objects: 143276, done.
...

[jasagredo]

I found a couple of things already:

1. The extra-prog-path is not being passed to cabal exec commands.
2. The extra-prog-path is not being passed to configureVCS eventhough there is a comment saying: -- TODO: pass progPathExtra on to 'configureVCS' (link)
3. globalProgPathExtra in savedGlobalFlags is not being sanitized, therefore leading to this singleton path: ["C:\\msys64\\usr\\bin\n,C:\\msys64..."] in this function

I have some on-going work. Last thing remaining is passing the extra-prog-path from cabal/config to cabal get (which I think doesn't read the configuration).

[jasagredo]

The changes in the linked PR should fix this. In particular I can do what is listed there without issues:

PS C:\Users\Javier\code> C:\\Users\\Javier\\code\\cabal\\dist-newstyle\\build\\x86_64-windows\\ghc-9.6.3\\cabal-install-3.11.0.0\\x\\cabal\\build\\cabal\\cabal.exe get network
Unpacking to network-3.1.4.0\
PS C:\Users\Javier\code> cd .\network-3.1.4.0\
PS C:\Users\Javier\code\network-3.1.4.0> C:\\Users\\Javier\\code\\cabal\\dist-newstyle\\build\\x86_64-windows\\ghc-9.6.3\\cabal-install-3.11.0.0\\x\\cabal\\build\\cabal\\cabal.exe build network:lib:network
<succeeds>

Cloning a repository in source-repository-package also works.

When resolving the ignoreInWindows from cabal-install/tests/UnitTests/Distribution/Client/VCS.hs, the empty lists provided to configureVCS should get the appropriate system paths to work (I think).

[hasufell]

Was this a regression compared to 3.6?

[gbaz]

Not to my knowledge. As far as I know, Cabal's path handling has been stable for many years. Many many years ago I extended the handling to work with build on 3.6. The issue here is about exec. I don't think that ever worked or ever was done.

The above-linked issue, which is speculated to be related but I think is not, was filed against 3.6, and the more recent manifestation on that thread is also with 3.6.