`process-load-or-reload` suddenly requires `stack`

[hvr]

When I M-x process-load-or-reload today I started getting

apply: Searching for program: no such file or directory, stack

This seems to have regressed recently with f4b1841 (@purcell) which incorrectly assumes that the presence of a stack.yml file implies that the user wants to use stack even though it was maybe just added there for convenience to other Stack users.

It's perfectly fine if haskell-mode adds support for Stack, but please, don't impose the non-default tool stack on users in its default configuration. Even if I happen to have stack installed, I certainly don't want it to hijack the REPL mode in the auto-mode.

[purcell]

I think perhaps we should just additionally check for the presence of a stack executable in this case before choosing stack-ghci.

[purcell]

(Done in 142334f)

[hvr]

Now I just need to figure out a way to keep haskell-mode from using stack-ghci even though I have stack in my path somewhere. Is there a way to configure the stack executable location? Then I could set that to some non-existent path.

[purcell]

Even if I happen to have stack installed, I certainly don't want it to hijack the REPL mode in the auto-mode.

The thing is, there's no "right" answer for "auto". I use stack in some cases, and for this "simplified" haskell project setup, I then need to set up a .dir-locals.el to override the haskell-process-type. This seems broken.

[hvr]

@purcell, you should probably place the check for a .cabal-sandbox before checking for the existence of the stack.yaml file

[purcell]

@purcell, you should probably place the check for a .cabal-sandbox before checking for the existence of the stack.yaml file

What this boils down to is that some (many?) projects will have both a *.cabal file and a stack.yml, so then there's no perfect choice for auto. My thinking is that if somebody added a stack.yml, then the project is specifically designed to work with stack.

[purcell]

What do you think would be the auto behaviour which would do the right thing for the greatest number of users? I'm really not sure. Perhaps most people don't care, because they simply customize haskell-process-type to suit their most common needs, but the more often we can avoid the need for a project-specific .dir-locals.el file, the better.

[hvr]

If a .cabal-sandbox folder exists, then the current working dir was clearly initialised by cabal sandbox init and hence is not supposed to be used via stack. OTOH, stack creates a different set of working dirs. So you can come up with a better heuristic for determining what the user wants.

My thinking is that if somebody added a stack.yml, then the project is specifically designed to work with stack.

And that's a wrong assumption. I have seen users submitting PRs to projects whose maintainer definitely doesn't use stack. Should I start submitting PRs to those projects removing the stack.yaml files again?

[purcell]

Like I say, I think there's no perfect answer, but checking for the .cabal-sandbox folder would be a really good heuristic to use.

[purcell]

Done. How does that look?

[purcell]

If you and others are strongly opposed to this, I'm happy to revert these changes, but I'd like us to do what we can to maximise the number of users for whom "auto" will do something sensible out of the box.

[hvr]

What do you think would be the auto behaviour which would do the right thing for the greatest number of users?

This depends on the percentage of stack vs cabal users, and on what the presence of a stack.yaml files actually means. Maybe auto should come with an additional customizable variable which controls the default bias towards cabal or stack.

This variable could say whether to:

• never use stack (even if the stack tool is available and a stack.yaml file exists and/or stack-sepcific working files)
• always prefer stack if a stack.yaml exists (even if cabal-specific working files exist)
• ask the user if there's no clear indication
• ...

It's a pity that stack departs from cabal so much that it requires separate code-paths rather than building on top of cabal :-(