Add support for tying repl/ghci/cabal-dev process type to project

[ozataman]

Perhaps a file like .haskell-process-type can be read per project root to determine what type should be used prior to checking the current global variable.

I often have 3-4 projects open at the same time, some depending on cabal repl and some using the plain ghci. I ended up creating "haskell-process-cabal" "haskell-process-ghci" functions I call using M-x to flip the global variable, which feels like a sub-par solution. It gets real annoying when you have to haskell-process-restart.

[hvr]

to understand your situation better: in which cases do you use plain ghci? are that still .cabal-controlled projects?

[ozataman]

You are right that we now have cabal repl as the single entry point for all cabal supported projects.

I think the question is identical to where you would use ghci directly vs. cabal repl. My answer is that I use ghci for self-standing scripts or programs that don't yet have a full cabal package definition. I use cabal repl for everything else, which recently made this issue less of a problem for me. Before cabal repl with sandbox support, it was a nightmare as using sandbox vs. using system-global packages needed different haskell-process-types. I'm not sure but others might also have cases where they are still using cabal-dev, although I personally don't see why not everyone would migrate their cabal-dev sandbox to cabal.

Nevertheless, I still deal with a lot of stand-alone applications (for one-off computations, etc.) that this does get from time to time annoying. I think the general realization is that the decision of haskell-process-type is less globally-determined and more per-project determined.

[hvr]

The reason I'm asking is that I had planned to implement something like

• use cabal repl whenever a .cabal project is detected
• use plain ghci when no .cabal project is detected

This is would be similiar to how haskell-compile decides how to compile the project.

Would that cover your use-cases? Can you think of cases where when this kind of auto-detection would fail?

[ozataman]

Sorry for the late answer here. That actually sounds pretty good. If we
assume that no-one will be using cabal-dev anymore, I can't imagine any
other reason why that would not work. It certainly covers my use-cases now
that we have Cabal 1.18.

It might still be good to leave a pressure valve in place for any other
cases we can't imagine such that if the "haskell-process-type" variable is
manually set to something, it gets used instead of the auto-detection. Not
sure if that's unneeded complexity though.

On Thu, Sep 12, 2013 at 3:01 AM, Herbert Valerio Riedel <
[email protected]> wrote:

The reason I'm asking is that I had planned to implement something like

• use cabal repl whenever a .cabal project is detected
• use plain ghci when no .cabal project is detected

This is would be similiar to how haskell-compilehttp://haskell.github.io/haskell-mode/manual/latest/#Compilationdecides how to compile the project.

Would that cover your use-cases? Can you think of cases where when this
kind of auto-detection would fail?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/198#issuecomment-24298769
.

[hvr]

Well, the code-base would greatly benefit if we would rip out all the quirks for supporting everything but cabal ghci and plain ghci sessions. Fwiw, even ghc-mod dropped support for cabal-dev recently.

[ozataman]

Following up from a few months ago and having thought about this during that time, I had a couple of comments on this thread:

• I would totally agree that it's fine to drop cabal-dev support. cabal repl and ghci are probably the only two things that need to be supported.
• Having now kept an eye on it for multiple months, I am fully sold on your suggestion - use cabal repl when there's a cabal file and use ghci when there is none. The only request I would make is to allow the user to override this through some means, even if inconvenient, as there are times I've wanted to turn off the cabal reliance and just drop down to plain simple ghci.
• I have found myself missing the ability to do cabal repl the-second-thing-defined-in-my-cabal-file. cabal repl by default picks the first entry in the cabal file. That gets annoying when you're working on, say, a background processor executable for your project which was defined as an additional executable in your cabal file. Not sure about the best way to support this, but am happy to open a separate ticket if you would like. This has become a really major wish for me.

Hope we get this soon! I would go ahead and do it myself if I were better acquainted with eLisp.

[chrisdone]

You can use .dir-locals.el, perhaps. Example, in your project directory make .dir-locals.el file:

((haskell-mode . ((haskell-process-type . ghci)))
 (cabal-mode . ((haskell-process-type . ghci))))

Now any buffer you open in that directory will have this variable set as ghci.

[purcell]

This can now probably be considered done, due to a change I just committed:

When haskell-process-type is set to 'auto (the new default), then the presence of a *.cabal file or a .cabal-sandbox directory in a parent directory will cause cabal-repl to be used. Otherwise, ghci will be used. This is in accordance with the suggestions above.

[purcell]

Hey @ozataman, I'm going to close this ticket, but if you still need to be able to specify a different cabal target in your cabal repl command line, please open a separate ticket.