Cater for stack and cabal users in one cradle

[ndmitchell]

Projects like Ghcide itself have both a Stack cradle and a Cabal cradle. For me personally, I want to use the Stack one, but other people prefer the Cabal one. Is there some way to support both in one cradle, with some either user preference or user detection to figure out which one to use?

[fendor]

Currently, there is not! Also, it is somewhat the point of the specification file that the user specifies exactly what they want. It could be a feature of ghcide/hls to ask the user which one they want to user, e.g. when multiple hie.yaml.* are present?

[ndmitchell]

I think the issue is if you check in the hie.yaml you've asked the project what it wants, not the user what they want.

Asking would be one option. Or maybe a file hie.yaml.which which doesn't get checked into version control, and names the hie.yaml file to use, defaulting to hie.yaml? Then users who want stack would echo hie.yaml.stack > hie.yaml.which and it would work? Just one possible mechanism, but something would be useful.

[fendor]

Or maybe a file hie.yaml.which which doesn't get checked into version control, and names the hie.yaml file to use, defaulting to hie.yaml?

Seems harder for newcomers of the ecosystem to me. They wouldn't know about the purpose of a hie.yaml file and why they should modify it, etc... Also, if you can do echo hie.yaml.stack > hie.yaml.which you can just do cp hie.yaml.stack hie.yaml straight away (and not check in any hie.yaml file).

Solving this at the Language Server level seems sensible to me. We could define a convention that the specification for stack needs to be named hie.yaml.stack and for cabal hie.yaml.cbl or hie.yaml.cabal and then have a LSP option to specify the user's preference in the presence of both. This would work globally. Then the Language Server just does the necessary copying.

Explicitly asking user to choose one of the two might have the advantage that new users will be aware of the relative importance of this file.

[Avi-D-coder]

A language server option is the right way to go, but in most cases also unnecessary. The correct cradle is usually the one for which build artifacts exist. If the user has not set the language server config we should just use check for dist-newstyle and .stack-work (this is already what I do in implict-hie).

[ndmitchell]

If I do cp hie.yaml.stack hie.yaml then I have a modified local checkout, and when upstream changes hie.yaml I end up diverging.

[fendor]

If the user has not set the language server config we should just use check for dist-newstyle and .stack-work

This is a nice addition, but currently my workflow is indeed to clone a project, write a hie.yaml and then open the project with vs codium. No dist-newstyle or .stack-work will exist at that point, so a global preference makes still sense to me.

when upstream changes hie.yaml I end up diverging

you are right, I did not think about that

[jneira]

hls is gitignoring hie.yaml and it is not in the repo. Not sure if it is the good option, though.

[ndmitchell]

I think hls not including a hie.yaml is terrible - it means hls is harder to get going with hls. Ghcide does include a hie.yaml - as do all my projects (e.g. HLint, Shake etc). My expectation is that eventually all projects will either want to ship a hie.yaml, or want to confirm that hls works with no hie.yaml.