cabal v2-exec ignores extra-prog-path when set in global config

[hasufell]

I was rather surprised when trying this on windows. I had expected cabal will expose extra-prog-path by adding it to the internal PATH, so I would be able to e.g. run mingw executables, such as cabal exec pacman -- --help. But I can't... instead I have to mess with the current shells PATH.

[Mikolaj]

Does it fail only on Windows?

cabal help exec says "The PATH is modified to make all executables in the dependency tree available (provided they have been built already)", but nothing about the other PATH modification.

It also says "It is convenient to run these tools in the same way cabal itself would.", which means if we extend the path for exec we should also extend it for every other command so that exec mimics how cabal calls exes from other commands, as required. But we probably do that already? Is extra-prog-path used in all cabal commands and used exactly the same as if PATH was extended by it?

Do we have any precedents of such local PATH extension in Haskell-land or in tools for other languages?

[jneira]

It works for me in windows setting extra-prog-path as cli option:

PS D:\dev\ws\haskell\cabal-test> cabal exec pacman --extra-prog-path=D:\dev\app\msys2-20180531\usr\bin  -- --version

 .--.                  Pacman v5.1.2 - libalpm v11.0.2
....
PS D:\dev\ws\haskell\cabal-test> where.exe pacman
INFORMACIÓN: no se pudo encontrar ningún archivo para los patrones dados.

how did you set extra-prog-path?

EDIT: it worked using cabal configure and setting it in cabal.project.local:

PS D:\dev\ws\haskell\cabal-test> cabal configure --extra-prog-path=D:\dev\app\msys2-20180531\usr\bin
'cabal.project.local' already exists, backing it up to 'cabal.project.local~'.
Build profile: -w ghc-8.10.4 -O1
In order, the following would be built (use -v for more details):
.......
PS D:\dev\ws\haskell\cabal-test> cat .\cabal.project.local
ignore-project: False
extra-prog-path: D:\dev\app\msys2-20180531\usr\bin

package *
  extra-prog-path: D:\dev\app\msys2-20180531\usr\bin
PS D:\dev\ws\haskell\cabal-test> cabal exec pacman  -- --version                                    
Resolving dependencies...

 .--.                  Pacman v5.1.2 - libalpm v11.0.2
......

[Mikolaj]

@jneira: I had an impression the issue is about PATH not being set inside the program you run via exec (e.g., try to run a script that just prints the PATH), not about the very program not found. Did I get it wrong? Could you experiment with such a script?

[jneira]

mmm as @hasufell mentioned explicitly cabal exec pacman -- --help, I 've tested something similar. However the experiment you propose is interesting, will do.

[hasufell]

I set extra-prog-path in global cabal.config, then try to run a program via cabal exec that is in one of those locations and it didn't work. The program was not found.

[jneira]

can reproduce in windows 7 with extra-prog-path: C:\msys64\usr\bin in the global config

D:\ws\haskell\hls>where pacman
INFORMACIÓN: no se pudo encontrar ningún archivo para los patrones dados.

D:\ws\haskell\hls>cabal v2-exec pacman -- --version
cabal: The program 'pacman' is required but it could not be found.


D:\ws\haskell\hls>cabal v1-exec pacman -- --version

 .--.                  Pacman v5.0.1 - libalpm v10.0.1

So it seems v2-exec is ignoring the extra-prog-path in the global config. It honours the cli option or the project config, so it could be a workaround for some use cases (not sure if this one would be one of them).
I guess it will reproduce in other os's.

[jneira]

Maybe related #2997 (global --extra-lib-dirs and --extra-include-dirs ignored): in our case the cli option is honoured and not sure how the diff between local/external packages could be applied (although cabal configure creates the config about for packages: *)

[Mikolaj]

@jneira, @hasufell: so I was wrong that the complaint is that PATH is not set inside the program being run? it's only about finding the program mentioned after exec thanks to the path?

Edit: In other words, "by adding it to the internal PATH" from the initial description is not relevant, the minimal outcome (finding the program) is relevant only?

[hasufell]

@Mikolaj I think we want both for msys2. Otherwise many binaries may fail if you execute them through cabal-exec, because they expect something else to exist (like curl, make, ...).

I also believe that this would be expected behavior.

[jneira]

I've done the experiment suggested by @Mikolaj and fortunately it seems that --extra-prog-path is adding the path to the global PATH within the code being executed:

PS D:\dev\ws\haskell\cabal-test> cabal exec ghc --extra-prog-path=D:\dev\app\msys2-20180531\usr\bin  -- -e "System.Environment.getEnv \`"PATH\`" >>= putStrLn"
C:\WINDOWS\system32;...;D:\dev\app\chocolatey\lib\ghc\tools\ghc-8.10.4\bin;D:\dev\app\msys2-20180531\usr\bin

PS D:\dev\ws\haskell\cabal-test> cabal exec ghc -- -e "System.Environment.getEnv \`"PATH\`" >>= putStrLn"
C:\WINDOWS\system32;...;D:\dev\app\chocolatey\lib\ghc\tools\ghc-8.10.4\bin

PS D:\dev\ws\haskell\cabal-test> $env:PATH
C:\WINDOWS\system32;...;D:\dev\app\chocolatey\lib\ghc\tools\ghc-8.10.4\bin;

So "only" we would need to make v2-exec honour the global config 😄

[Mikolaj]

Time for begging, then. :)

[jasagredo]

This works already, probably fixed by #9527

PS> cabal exec pacman -- --help
usage:  pacman <operation> [...]
operations:
    pacman {-h --help}
    pacman {-V --version}
    pacman {-D --database} <options> <package(s)>
    pacman {-F --files}    [options] [file(s)]
    pacman {-Q --query}    [options] [package(s)]
    pacman {-R --remove}   [options] <package(s)>
    pacman {-S --sync}     [options] [package(s)]
    pacman {-T --deptest}  [options] [package(s)]
    pacman {-U --upgrade}  [options] <file(s)>

use 'pacman {-h --help}' with an operation for available options