rules_haskell
rules_haskell copied to clipboard
bazel and stan https://kowainik.github.io/projects/stan
Is your feature request related to a problem? Please describe.
I've been trying to configure stan (https://kowainik.github.io/projects/stan) on my haskell codebase. The program needs the *.hie
file generated by -fwrite-ide-info.
By default these files are generated in the sandbox so stan can't access them.|
I've tried giving the different sandbox access to my host folder build --sandbox_writable_path=/home/teto/project/.hie
but the .hie files get
$ ls -l
Main.hie
Numeric
Porcupine.hie
Scoring.hie
Text
_actions
volatile-status.txt
Utils
k8-fastbuild
_tmp
stable-status.txt
(Why does bazel create k8-fastbuild/_tmp/_action in this subfolder ?)
then upon running stan, I get:
stan: /home/teto/nova/jinko2/user_cache/f3097620197e6c203645e1230d1ae88c/sandbox/inaccessibleHelperDir: getDirectoryContents:openDirStream: permission denied (Permission denied)
. It seems the .hie files can't be used anyway because they recorded the filepaths in the sandbox which don't match the host.
As a general question, does anyone have knowledge of a similar deployment and is there an idea to work around these limitations ? ghcide can generate the .hie files so that may be a solution instead of counting on bazel
If you can afford running it outside of a normal bazel build
/bazel test
, then yeah, manually running ghcide (or plain ghci) with -fwrite-ide-info
sounds like a good mid-term solution.
Ideally I think haskell_library
should be able to directly output the .hie
files, but as you point out these files seem to embed the absolute path to the source files in them, which makes things a bit painful (though that might just be a consequence of specifying -hiedir
).
It seems the .hie files can't be used anyway because they recorded the filepaths in the sandbox which don't match the host.
Just ran a few tests and it looks like the filepath that's recorded in the hie file is the exact one that was passed to ghc (so it's an absolute path iff we passed an absolute path to ghc). Maybe we can modify the ghc call to pass relative filenames where possible so that the hie files contain relative filenames too
is it possible though if every component is in a different sandbox ? Rewriting the paths as a postprocessing step could work but on short term, I may go along with ghcide. Is a bump of rules_haskell to ghcide 0.3 on the roadmap :D ?
@aherrmann has worked quite a bit on ghcide support for Bazel. I imagine that he may have some opinions about how to best solve this sort of problems, but he is on holidays until the end of next week.
So if you have not found a fully satisfactory solution by then, you may get more ideas when @aherrmann comes back.
@regnat's suggestion sounds like a good workaround and it seems to be working with ghci
from haskell_repl
. For example the following command generates hie files for one of the test cases in the rules_haskell repository:
$ nix-shell --pure --run 'bazel run //tests/multi_repl:c_multi_repl -- -fwrite-ide-info -hiedir hiefiles -e "()"'
$ tree hiefiles
hiefiles
├── A
│ └── A.hie
└── BC
├── B.hie
└── C.hie
2 directories, 3 files
I haven't tested it with stan
, but looking at the generated hie files, the paths are relative to the repository root.
Extending haskell_library
to be able to directly produce .hie
files sounds very sensible. We could make this configurable as a feature flag or a user defined build setting.
Is a bump of rules_haskell to ghcide 0.3 on the roadmap :D ?
Does the update require a change to the hie-bios file, or is it a matter of building a more recent version of ghcide? If the latter then you can do this on the use-site by defining a more recent commit in the custom stack snapshot.
This is a more focused proposal than #1428. If implemented, best to start here before generalising.