Paths in Paths_ module wrong for local/vendored packages

[nomeata]

Still trying to use cabal v2-commands to build a project where the authors use stack. I ran into this problem:

A number of local libraries and executable have data-files, and use them during execution, based on the paths in the generated Paths_foo module. In one case, a Setup.hs even writes generated files into the data directory.

But when I build these with cabal new-build, they are not installed into the paths that are included in the Paths directory:

$ cat ./dist-newstyle/build/x86_64-linux/ghc-8.7.20180822/asterius-0.0.1/build/autogen/Paths_asterius.hs
…
bindir     = "/home/jojo/.cabal/bin"
libdir     = "/home/jojo/.cabal/lib/x86_64-linux-ghc-8.7.20180822/asterius-0.0.1-inplace"
dynlibdir  = "/home/jojo/.cabal/lib/x86_64-linux-ghc-8.7.20180822"
datadir    = "/home/jojo/.cabal/share/x86_64-linux-ghc-8.7.20180822/asterius-0.0.1"
libexecdir = "/home/jojo/.cabal/libexec/x86_64-linux-ghc-8.7.20180822/asterius-0.0.1"
sysconfdir = "/home/jojo/.cabal/etc"

getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir, getSysconfDir :: IO FilePath
getBinDir = catchIO (getEnv "asterius_bindir") (\_ -> return bindir)
getLibDir = catchIO (getEnv "asterius_libdir") (\_ -> return libdir)
getDynLibDir = catchIO (getEnv "asterius_dynlibdir") (\_ -> return dynlibdir)
getDataDir = catchIO (getEnv "asterius_datadir") (\_ -> return datadir)
getLibexecDir = catchIO (getEnv "asterius_libexecdir") (\_ -> return libexecdir)
getSysconfDir = catchIO (getEnv "asterius_sysconfdir") (\_ -> return sysconfdir)

It looks to me as if these are the paths that one would have after a v1-style installation.

The code also has support for overriding these paths using environment variables… but I am not sure who should do the overriding (cabal new-exec?), and what to override them with.

[hvr]

This is a long-standing known issue; for packages which do not get installed into the nix-style store, we deliberately decided to go with the less trivial choice to tolerate incorrect paths in the Paths_ module, and we instead use env-vars (set by new-test, new-run, new-build etc for their sub-processes) whenever they're invoked.

Consequently, if you don't new-install something (so that the artifact ends up in the nix-style store), if you invoke binaries directly (e.g. not via cabal new-run or new-test) it's your responsibility to set the env-vars accordingly; if you invoke things via a sub-process of cabal and the env-vars aren't properly set, you've hit one of the few places we missed to setup the envs (iow, a bug).

[nomeata]

Ok, that makes sense!

Does new-build set the environment variables? E.g. during Setup? I can check later, but it did not seem to be the case.

[nomeata]

Yes, indeed: A custom Setup that uses the Path_… module sees the “wrong” paths:
https://github.com/tweag/asterius/blob/3b58175e8b6fd5e208f587b00c9a00354ef1339a/ghc-toolkit/Setup.hs#L37

(This file also does some fishy stuff like copying these paths into another generated Haskell file, don’t get distracted from that.)

[nomeata]

After browsing the code a bit, it seems that you are only seeing the dataDir environment variable, in dataDirEnvVarForPackage in Distribution.Client.ProjectPlanning.Types, but not the other paths (bindir in this particular example)