Ignore stack.yaml and stack.yaml.lock.

[yuanwang-wf]

I ran into some problems when trying to cabal new-build the project, so I hacked together a stack.yaml to support stack build.

[patrickt]

Hi there. Thanks for submitting this PR! We’d prefer not to have an official stack.yaml file; we have a lot of surface area to maintain, and officially supporting two build systems is not something we’re prepared to do, given how many submodules we depend on. I’ve considered linking to unofficial stack.yaml files, given that @jkachmar threw one together, but I’ll leave the decision to @robrix as to whether we should do that. (I think we should .gitignore stack.yaml files so that end-users who want to use Stack don’t have their worktrees clogged.)

@yuanwang-wf, would you mind (in this PR or in another) outlining what failures with cabal new-build you encountered?

[yuanwang-wf]

Hey @patrickt, makes sense.

the error I am seeing is

cabal: Could not resolve dependencies:
[__0] trying: haskell-tree-sitter-0.1.0 (user goal)
[__1] trying: template-haskell-2.13.0.0/installed-2.1... (dependency of
haskell-tree-sitter)
[__2] trying: pretty-1.1.3.6/installed-1.1... (dependency of template-haskell)
[__3] trying: deepseq-1.4.3.0/installed-1.4... (dependency of pretty)
[__4] next goal: semantic (user goal)
[__4] rejecting: semantic-0.6.0 (conflict: deepseq =>
array==0.5.2.0/installed-0.5..., semantic => array^>=0.5.3.0)
[__4] rejecting: semantic-0.0.0 (constraint from user target requires ==0.6.0)
[__4] fail (backjumping, conflict set: deepseq, semantic)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: pretty, template-haskell, semantic,
deepseq, haskell-tree-sitter

if you want, I can change the pull request to add stack.yaml and stack.yaml.lock into .gitignore, add point to stack.yaml in readme

[patrickt]

@yuanwang-wf I’d accept a PR to ignore the stack.yaml and stack.yaml.lock + add the link (though please mention it’s unofficial and not guaranteed to stay in sync with our changes).

The build errors look like you might be on GHC 8.4—we require 8.6 due to our use of DerivingVia. Can you confirm if that’s the case? If so, you could either use ghcup to sandbox a new GHC 8.6 installation, or you could continue with Stack.

[yuanwang-wf]

oh, you are right. I am on GHC 8.4, thank you!

[robrix]

Thank you so much @yuanwang-wf!