Command line flag for project root directory?

[bscottm]

Would it be reasonably easy to add a command line flag that directs ghc-mod to initially chdir into a (presumably project root) directory? This would make ghc-mod play better with cabal exec and stack exec and reduces global utility install pollution.

Or has this been proposed before but ultimately rejected? (I didn't see anything related, on a quick scan through the issues.)

[DanielG]

Can you explain the use case for this a bit more? Just a flag that chdirs somewhere hardly seems worthwhile, just use sh -c 'cd foo/bar/baz; ghc-mod "$@"' or some such :)

Now support for forcing a specific project type (what the code calls 'cradle') to be used would be a more reasonable request and probably easy to add. However I would prefer not to add more features to ghc-mod's command line interface than absolutely necessary. It's already a horrible mess and it won't get better by adding more stuff.

The library interface, used by haskell-ide-engine for example, could surely use a way to specify exactly what kind of project is desired though.

[bscottm]

@DanielG: The chdir has to be done after ghc-mod starts, viz:

cd <place-where-ghc-mod-was-compiled>
cabal exec ghc-mod -- --chdir "<user-project-directory>" [other ghc-mod flags]

or (quelle horreur!!!):

cd <place-where-ghc-mod-was-compiled>
stack exec ghc-mod -- --chdir "<user-project-directory>" [other ghc-mod-flags]

The use case for this is the SublimeHaskell plugin, where I've encountered at least one instance when a newbie has created a cabal sandbox, build and installed ghc-mod and ended up entirely perplexed as to why SublimeHaskell doesn't work. Adding the ability to execute ghc-mod via the cabal or stack execution wrapper fixes this one problem.

OTOH, I do wonder if haskell-ide-engine and LSP are sufficiently far along that they both can put SublimeHaskell out of business.

[DanielG]

I still don't see a reason why cabal exec sh -c 'cd wherever/; ghc-mod "$@"' check Foo.hs wouldn't work though :)

[DanielG]

As for h-i-e you'll want to ask @alanz.

[alanz]

In HIE, when the client (i.e. IDE) starts up the server, it sends through a project root directory. HIE then does a ghc-mod API call to change to that directory, and then operates.

It is up to the client to identify and start up the appropriate HIE executable, as they are specific to the GHC version.

And HIE is not on stackage yet, waiting for ghc-mod. Nudge @DanielG

[bscottm]

@DanielG: I'll give your solution a try... I'm not particularly keen on using the shell to start anything due to the interesting security holes that it can create. It's also not cross-platform: a lot of SublimeHaskell users are on Windows. Using subprocess.Popen to execute a shell command line script is explicitly not recommended in the Python documentation.

Also, SublimeHaskell uses legacy-interactive.

@alanz: I'm speculating that SublimeHaskell might no longer be necessary if HIE and LSP does what's done by SublimeHaskell and its supported backends.

[DanielG]

I don't think security is a valid arguments against using this particular shell script but indeed I though windows support might be a concern. While I'm not happy about adding more stuff you can give it a shot if you want.

@alanz remind me why we had to expose the commandline parser again? Every time I look at that code I get have a really, really bad feeling about it :/

[alanz]

Because hie parses the ghc-mod options, and passes them though. So rather use one parser, than have to keep two in sync.