Run 'stack ghc' from project root instead of directory of current file

[mrkkrp]

Yesod ecosystem kinda likes to keep data in separate files (one for config, another one to describe database entities, etc). Then those files are embeded into Haskell modules via file-embed or similar TH magic. Since paths to the files are relative (absolute paths would not be flexible at all), current working directory is really important. This leads to the situation when project compiles fine from command line but Flycheck compilation fails (often without any error messages until I investigate it with flycheck-compile), because it calls stack ghc … from current directory, not project root directory.

My question is how to make Flycheck internally run stack ghc … command from project's root (where Cabal file is found) every time, instead of running it from current directory (where file I edit is located).

I can imagine not everyone is having this sort of problem, so a hint how I can change it just in my configuration would suffice. At the same time, it wouldn't be bad in any sense if stack ghc … ran always from project's root, I don't see any problems with making this behavior default.

I previously tried to work around this issue, but now it begins to be real hassle that I can't handle manually. I'm already having problems with flycheck-haskell because I need to be careful not to upgrade my local version (with changes from #48).

[swsnr]

I'm sorry to say that you can't currently change the working directory in Flycheck. It's a long standing issue, see flycheck/flycheck#312, but it's not a priority for me, because I'm personally not affected by this short coming of Flycheck.

It's also not that easy to implement as it needs a rather deep change to the internal API for picking syntax checkers, because we need to compute the working directory before starting the syntax check and then drag it along all the way to error parsing to properly resolve relative file names. Unfortunately Flycheck does not provide any infrastructure for this currently.

I'm closing this issue since it's essentially an upstream problem in Flycheck itself.

[mrkkrp]

Implementing this will make me diverge from schedule… On the other hand I cannot really continue without tools that work in my circumstances. So it turns out that this things has been waiting for me.

I like that idea with :cwd described by @rejeep. I think that's how it should work.

Can you describe step by step how this feature should be implemented properly (how you would implement it if you had time and motivation) from your point of view? (E.g. start here, because …, then implement …, change …, etc.). I don't really know how Flycheck works and typically I need to spend several hours to be in position to contribute to large projects. If you could give me some hints your several minutes would save me several hours (or more).

[swsnr]

@mrkkrp I'm sorry, but I do not know how I'd implement it. If I did I'd have written it down on the corresponding issue.

I do know, though, that it is not an easy change. There are two challenges that I see immediately:

• Flycheck implicitly relies on default-directory in many places. Specifically we do expand-directory with no directory argument all over the place. An implementation needs to identify all these places, decide whether they need the buffer's default-directory or really the working directory of the syntax checker, and make sure to pass the checker's working directory to all these places.
• Flycheck needs to access the working directory at two different places that are somewhat "far away" from each other: The invocation of the syntax checker, and then the expansion of relative filenames after error parsing. To make sure that the working directory matches at both places we cannot re-compute it at the second place; instead Flycheck must pass the working directory used for checker invocation all the way through the process sentinel and error parsing.

Currently we attach a couple of ad hoc properties to the process object but I'd not like to expand this “strategy”. As part of this change I'd like to see a generic "syntax checking context" struct being introduced that wraps up all the information about the current syntax check (i.e. checker being used, buffer being checked, and then also the working directory) and makes that available at all later places, e.g. error parsing, error filtering, etc.

[mrkkrp]

All this stuff makes me feel very sad.

[swsnr]

@mrkkrp I didn't anticipate this use case when I wrote these parts of Flycheck, and it's all too easy to rely on all the implicit global state in Emacs. Besides, with this design decision being so close to Flycheck's core it's also one of the oldest decisions in Flycheck, and my Emacs Lisp skills and my understanding of Emacs were worse than they are today back then.

I'm sorry that my work is not good enough for your requirements.

[mrkkrp]

@lunaryorn, No worries, Flycheck is great, that thing is my problem.

[swsnr]

@mrkkrp Thank you 😊 Please don't hesitate to ask if you need any help and I'll do my very best to help you!