Environment files get written to $TMP when using cabal scripts

[georgefst]

Running cabal run --write-ghc-environment-files=always on a cabal script doesn't actually write a GHC environment file.

It would be great if it did, since it would mean that after the first run, straightforward calls to ghc and runghc would just work, and haskell-language-server, for one, would be able to load the file without requiring any setup.

Is there any fundamental reason why this shouldn't just work?

I've actually ended up writing a hacky little script to parse the build-depends field and pass all the package names to cabal install --package-env . --lib, but it would be nice to have a proper solution.

[fgaz]

Does adding --package-env=/absolute/path/to/env work? It might be possible that cabal is writing the env file in the temporary "fake package" directory

[georgefst]

--package-env doesn't seem to be a valid flag to any command other than install.

But you're right that the environment file does get written to disk, albeit temporarily. I've now scripted a slightly less hacky solution based on recursively watching /tmp and copying the file out.

Perhaps the solution to #6977 will solve this as a side-effect...

[fgaz]

Ok so this is an actual bug (I don't think anyone wants cabal to put the env file in /tmp by default)

[bacchanalia]

this issue may have been resolved by #7851, since script builds are now cached on disk

[jneira]

hmm maybe the title should be changed but iiuc the issue goals were:

1. being able to load the script with a plain ghci/ghc
2. to make easier hls load the script

Afaik #7851 does not resolve 1 but it does for 2, as a simple cabal cradle would be able to load it with cabal repl script.hs
@georgefst what do you think about closing?

[georgefst]

I'll need to build Cabal HEAD and investigate in the coming days, to see what the ergonomics are now like.

[georgefst]

I don't think this can really be closed, as the issue still stands.

But the improvements to scripts do make it a lesser issue. Indeed, for my use case, the desire to generate environment files entirely disappears, since the benefits of calling ghc/ghci directly no longer apply:

• We can get a REPL with the right environment using cabal repl
• build and run take only a fraction of a second when no work needs to be done

So thanks @bacchanalia!

[georgefst]

Incidentally, I've found that the existence of a cabal.project file (say, a totally empty one) is enough to avoid this behaviour. Naively, I would've thought that scripts ignore cabal.project files by default, but this is evidently not the case. Note that when a cabal.project file is picked up, dist-newstyle also ends up in the current directory, rather than /tmp.