Running a test watcher alongside haskell-language-server

[danbroooks]

I have installed HLS and it works great! I have however, come up against a slight issue with my workflow. I have a stack command that I run to watch file changes, and run my test suite on changes, the command is:

stack build --fast --test --file-watch --flag app:library-only --flag app:dev

This unfortunately conflicts with HLS, as when this command is running and I also have vim open with HLS active, whenever I make a change to a file my test process gets stuck in a loop:

app> blocking for directory lock on /home/dan/projects/app/.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build-lock
app> still blocking for directory lock on /home/dan/projects/app/stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build-lock; maybe another Stack process is running?
app> still blocking for directory lock on /home/dan/projects/app/stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build-lock; maybe another Stack process is running?
app> still blocking for directory lock on /home/dan/projects/app/stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build-lock; maybe another Stack process is running?
app> still blocking for directory lock on /home/dan/projects/app/stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build-lock; maybe another Stack process is running?

Is there a way around this? What is the setup typically for this kind of workflow? Could I use HLS to run the tests on file change? (that is probably beyond the scope of this project...?)

Is there a way I can run stack so that is isn't actively compiling, and just runs the tests every time the tests have re-compiled?

[jneira]

Hi, thanks for reporting this.

A quick workaround would be set a different .stack-work for hls so the build triggered by hls will not interfere with your stack build --fast --test....
To do that you will have to create a explicit hie.yaml config file and set stack-yaml: "stack.hls.yaml" (see https://github.com/mpickering/hie-bios#stack for more details)
In that alternative stack.hls.yaml you could set a different work-dir for hls

I would argue that it is a stack bug cause it should support concurrent builds, even with --file-watch. Maybe it could only block in a more fine-grained way and only make wait to second process while the first is compiling.

[danbroooks]

Thanks so much for the speedy response/workaround, I was struggling to get my workaround idea to work myself :(

I was originally going to open this issue against stack, when I realised that the "other Stack process" was HLS, so I opened the issue here. Do you think opening an issue against Stack is worth doing still?

Finally, is there any way to set stack flags via the hie.yaml config? It would be handy just to set the work-dir as a flag in there, otherwise I need to duplicate my stack.yaml file, this is no big deal if not as this is just a workaround for now, but thought I would ask if it is possible.

Thanks again!

[jneira]

Finally, is there any way to set stack flags via the hie.yaml config?

I am afraid it is not. hie-bios, the lib responsable of read hie.yaml and query the build tool for the info hls needs does not have that feature. We have to consider carefully that cause adding that feature has its own caveats and hie-bios will change damatically its way to communicate with the build tools in the mid term so maybe that change will not make sense after that.
//cc @fendor

Do you think opening an issue against Stack is worth doing still?

Well, maybe it is worth even only to make it know to other stack users.
But the message is clear and it is set on purpose, so they assume parallel builds are not supported. It would be a new feature.

Afaik cabal supports parallel builds, although sometimes you hit a bug doing it so it is possible 😄

[Vlix]

I have kind of the same problem this issue has a work-around for, but I was wondering if it might be possible to set the optimization/flags for stack in HLS? That way when HLS rebuilds something, stack doesn't have to ALSO rebuild again, because HLS builds with -O2, and when I run stack directly, I use --fast (-O0) so that I don't have to wait so long.

At least the "make HLS use a different work directory" is a decent work-around, so I'm happy I found this issue.

[michaelpj]

HLS now uses a separate working directory so it doesn't collide with the build tool. Or at least that's true for cabal, is it true for stack also? @fendor ?

[fendor]

For stack, we don't change the build directory as stack claims to only support relative paths and we want to pass in an absolute path, e.g. XDG_CONFIG/ghcide/stack-work-dir....

Thus, the issue is still relevant and we would like to fix that in the future.

Relevant stack issue: commercialhaskell/stack#6135