The helper script can be run in a CI action or a pre-commit git hook (very useful, I also use that for hlint).
If run as a pre-commit hook, wouldn't it always complain about a dirty working directory then as before a commit changes aren't commited yet?
And finally, a stylish-haskell helper script that detects if code files are dirty. Can be useful for CI, although manually calling it can be nice if you would rather first implement then beautify.
@hecate I do not fully understand what's the best way of using stylish-haskell in my workflow:
On the one hand I'm too lazy for calling the tool itself for each single file of my project.
When using the helper script, I usually commit my changes first, then run the heloer script and --amend the formatting changes to the previous commit. This only works though when always committing all changes from the repo, not only those of a single file or even a chosen patch set.
Why does the helper script care about a dirty working directory?
This one pulls in Postgres. I still have to decide on how to persist data, will probably ask around in the SocialHub thread quite soon.
Note to self for further reading: https://www.haskelltutorials.com/odd-jobs/haskell-job-queues-ultimate-guide.html
The DHT layer also needs to schedule regular maintenance jobs, but as those won't pile up such an asynchronous background processing worker queue isn't necessary.
I'll take care of this at the next larger feature branch merge.
Can you point to some examples for this convention? The Main.hs didn't always reside in src/, but I moved it there after looking at other packages (I guess pandoc was one of those).
b8eeb852da
Merge pull request 'Linting integration' (#17) from Hecate/Hash2Pub:hlint-configuration into master
