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 :-(

[purcell]

Perhaps if we had something like a haskell-process-stack var which was initialized to (executable-find "stack"), then we could do stack-related stuff only if that variable is set. And people who don't want to use stack could set that var to nil. It's really just a question of where to put these hints, I suppose.

[hvr]

deb809b is already an improvement. I think cabal also uses dist/ (located in the folder where the .cabal folder exists) exclusively (and stack probably uses something differently named from dist/). So that'd be another distinguishing feature of cabal vs stack you could check for.

PS: when you successfully cabal configure, dist/setup-config is created to keep cabal's state.

[purcell]

Yeah, there's a .stack-work dir which is equivalent to both .cabal-sandbox and dist.

[purcell]

When neither .cabal-sandbox or .stack-work exist - and when both a .cabal file and a stack.yml file are present - it'd be nice to prompt the user to create one or the other.

[hvr]

yeah, I agree (assuming a stack executable can be found, there's no point in asking a question if you can't follow through with both alternatives)

PS: and I assume the presence of dist/setup-config counts as well as? (I almost never use sandboxes)

[purcell]

And assuming a cabal executable can be found, of course -- you can use stack without one!

[hvr]

That's only mostly true... stack still calls out to cabal if it needs to compute install-plans (i.e. if you need to use packages outside the stackage-set) :-)

[ivan-m]

Don't search for .cabal-sandbox as a user might have a non-standard sandbox location; you're better off searching for cabal.sandbox.config (as I believe that file can't be renamed).

[purcell]

Makes sense - done.

I'll quit fiddling with this now, though -- if there's consensus that this is all misguided, or that there's a better approach, we can feel free to throw out these changes.

[hvr]

@ivan-m good point... there's actually also ongoing work (see haskell/cabal#2810) making it possible to place the cabal.sandbox.config in some parent folder.

However, you can actually rename that config file via

    --sandbox-config-file=FILE     Set an alternate location for the sandbox
                                   config file (default:
                                   './cabal.sandbox.config')

But that's probably not done very often (except for build-bots and/or specific build-scripts)

[gracjan]

So how does this work now?

There needs to be a section in manual that describes current behavior. @purcell: Can you write/update one?

[purcell]

Yes, there was also no description of the previous logic. I have updated the documentation for the haskell-process-type var to describe both the old and new logic: 3a03999.