explicit stack / cabal / .. cradle setting

[nrolland]

When using ghc-mod with stack, the mode gets deactivated when it encounters a "dist" directory.

That means relying on the side effects from some aggressive "cabal configure" of some other tools. As of now it seems that we rely on heuristics which might be brittle.

in Cradle.hs

findCradle' :: (IOish m, GmOut m) => FilePath -> m Cradle
findCradle' dir = run $
    msum [ stackCradle dir
         , cabalCradle dir
         , sandboxCradle dir
         , plainCradle dir
         ]

Would it make sense to add some explicit input flag to pin down a specific mode ?

[DanielG]

+1 but we have to be careful how we do this. I'm still on the fence about weather we should give ghc-mod an (emacs) .dir-locals style configuration mechanism or just have the frontends handle configuration using whatever is appropriate for the specific frontend and just have them communicate the options to ghc-mod using flags.

I just don't want to end up with a mixture of having some options only available as flags and some only as a file that you drop somewhere. Right now we have that ghc-mod.package-db-stack file that can override cradle stuff so if we're going to make this configurable we need to figure out how we're going to handle preferences coming from the user first.

[nrolland]

we can have a hierarchy of options like what is here https://github.com/zerobuzz/configifier/blob/master/examples/Main.hs

It provides for a sane chain of - overridable - priorities

    sources <- sequence
        [ YamlString  <$> SBS.readFile "examples/config.yaml"
        , ShellEnv    <$> getEnvironment
        , CommandLine <$> getArgs
        ]

with some type safety and nested config points

Example session:
$ configifier-example
[...]
accessing config values:
(Tagged Id 8001 :*> (Id "localhost" :*> JustO (Id "fost")))
Just "fost"
8001

$ FRONTEND_BIND_PORT=31 configifier-example
[...]
accessing config values:
(Tagged Id 31 :*> (Id "localhost" :*> JustO (Id "fost")))
Just "fost"
31

$ FRONTEND_BIND_PORT=31 configifier-example --frontend-bind-port 15
[...]
accessing config values:
(Tagged Id 15 :*> (Id "localhost" :*> JustO (Id "fost")))
Just "fost"
15

$ configifier-example --frontend-expose-host "false"
[...]
configifier-example: CommandLinePrimitiveOtherError (ShellEnvNoParse {shellEnvNoParseType = "Text", shellEnvNoParseValue = "false", shellEnvNoParseMsg = "when expecting a Text, encountered Boolean instead"})

$ configifier-example --frontend-expose-host "\"false\""
[...]
accessing config values:
(Tagged Id 8001 :*> (Id "localhost" :*> JustO (Id "false")))
Just "false"
8001
$ configifier-example --config examples/config2.yaml
[...]
backend:
  bind_host: arrr
  bind_port: 281
[...]

[DanielG]

Sounds interesting. I like the idea of having all configuration options available in an increasingly user facing location and having those being closer to the user (config file, env) able to override frontend facing commandline options.

[nrolland]

absolutely agree with that. the more gets surfaced out the better it is.

It pins down behavior and gives more determinism, A "smart" setting can still remain, although the less smart the better

[mwotton]

This would be helpful, I think. I have found that the only thing that seems to work when ghc-mod gets wedged on "hidden-package hspec" stuff when checking test files is deleting .stack-work/dist and not having stack build --filewatch running in the background, which is a little aggravating.

orb ➜  git:(hermes) ✗ ghc-mod check test/MandrillResponseSpec.hs
test/MandrillResponseSpec.hs:9:18:Could not find module ‘Test.Hspec’It is a member of the hidden package ‘hspec-2.1.10@hspec_6v6j22VJyLg98uGX19QkK8’.Perhaps you need to add ‘hspec’ to the build-depends in your .cabal file.Use -v to see a list of the files searched for.
orb ➜  git:(hermes) ✗ rm -rf .stack-work/dist                   
orb ➜  git:(hermes) ✗ ghc-mod check test/MandrillResponseSpec.hs
hermes-0.1.0.0: configure
Configuring hermes-0.1.0.0...

[nrolland]

@mwotton fwiw I have compiled my own version of ghc-mod which defaults to stack in the meantime https://github.com/nrolland/ghc-mod/tree/nostackoverride

it should be as easy as stack install to use it

[mwotton]

@nrolland you deadset legend :) thanks, that's really helpful.

[DanielG]

@mwotton That's an unrelated bug actually, I never managed to reproduce it when I wanted it to happen could you open another bug report and record any clues as to how this usually happens so I can fix it for good?

[mwotton]

@DanielG i'll dump what i have. It's frustrating because it's intermittent.

[DanielG]

I know I've run into it myself but I don't use stack regularly enough to get the info I need to reproduce the problem.

[mwotton]

yeah, but i got it pre-stack too. it's confusing.

[DanielG]

Oh that problem has been fixed in master AFAIK, but stack still has it (or something simmilar) for some reason.