Add extra explicit arguments to call cradles

[ndmitchell]

As requested in https://github.com/digital-asset/ghcide/issues/62#issuecomment-531934756, it would be nice to write:

cradle:
    stack:
    arguments:
        - -Wunused-binds
        - -Wunused-imports

Seems like it should apply to all cradles.

[ndmitchell]

CC @fendor @jacg

[mpickering]

I think that you should add these options to your stack.yaml?

[jacg]

It works, but it the warnings I want in my IDE aren't necessarily the same options I want during compilation.

[fendor]

I think, we have to be careful to not reinvent the wheel with the specification of hie.yaml.
If we continue to rapidly adding features, we might soon have an unmaintainable behemoth.

However, I think it is worth implementing custom arguments in one way or another. For example, in the case of a stack cradle, if projects support more than one snapshot, e.g. has multiple stack-*.yaml files, hie-bios automatically uses stack.yaml. Let's assume this stack.yaml uses ghc 8.6.5. However, sometimes I would rather want to use stack-8.6.4.yaml, since my version of hie/ghcide is compiled with ghc 8.6.4.
Currently, to work around this, we can copy stack-8.6.4.yaml to stack.yaml. However, now we have to careful to not commit the changes to stack.yaml and revert these changes if we want to switch the branch, which is not optimal.
Thus, in my opinion, it would be useful if we can specify the stack.yaml to use in hie.yaml. Consequentially, custom arguments for the cradle build-tools might make sense.

[jacg]

I'm certainly very uncomfortable with having to edit a project's version-controlled files, just to get my IDE to behave the way I want it to, and then to have to juggle these edits in stashes whenever I want to switch branch or rebase.

[fendor]

I want to try tackle this feature.
We will have to discuss a potential API.

[vilem-ff]

+1 for allowing different GHC options than those listed in the stack.yaml. At the moment I have to make sure I don't accidentally commit my stack.yaml and/or don't forget to commit those changes from stack.yaml that I did actually mean to commit.

[fendor]

I have been thinking about this feature request.
In the issue, it is described to pass in ghc arguments to the underlying tools and essentially extends all cradles to implicitly be direct cradles, too. This does not solve the problem described in #44 (comment), though. NOTE: you can actually work-around the described issue by defining an env variable STACK_YAML. All stack-commands will then use this env variable. (@vilem-ff maybe interesting for you)

Then, I thought about adding a global field for custom cradle arguments.
However, having a global field for it, such as

cradle: ....
dependencies: ...
arguments: ...

has the issue that this arguments fields doesnt do anything for most cradles, e.g. for none and direct, and you can debate bios, since the flags are all going to be passed into a ghc session, eventually, and I dont think you need custom cradle arguments for a ghc session.
So, it feels like the only cradle types that would profit from this are cabal and stack.
I think this indicates that custom arguments to the underlying tools (cabal and stack) could be more useful than general extra explicit arguments (but feel free to disagree).
Assuming only stack and cabal need custom arguments, a potential api could be:

cradle:
  stack:
    ...
  arguments:
    - "--stack-yaml=..."

Something similar for cabal.

Problems I see with this approach:

• Wrappers for hie/hls/ghcide are harder to write, since the ghc version to use may depend on these arguments.
• It is not nicely generalized. Adding another cradle forces us to rewrite parsing logic, etc...

To mitigate the former problem we could extend the API, to e.g. expose the path to the ghc version to use for the cradle.

Any opinions on these thoughts? Are we looking for explicit ghc arguments for the cradle, or rather arguments to the tools cabal and stack?

[alanz]

In my mind we should allow additional options that might be passed to the CLI versions of stack or cabal.

[konn]

I'm planning to use HLS with my corporate project, maintained as a stack project, which consists of dozens of packages with heavy optimisation/type-checking burdens.
As a daily workaround to check if they compile, I normally pass --work-dir=.stack-prof --fast --ghc-options="-O0 -dynamic" flags to stack; otherwise it takes more than an hour to compile, which is too much for IDE-thing.

All these configurations could be specified and managed by stack.yaml thing, so I think to provide an ability to customise the stack.yaml parameter would be at least enough.

[AshleyYakeley]

I'd really like to be able to pass --no-docker to stack.

[hkailahi]

This would be a very useful feature.

As a stack user, I frequently run stack build --fast and stack test --fast locally, which collides with my HLS stack configuration. I believe this is the source of a lot of unnecessary recompilation (Compiling <blah> [Optimisation flags changed]).

[fendor]

hie-bios allows now to specify the cabal.project and stack.yaml for the session.
I think we can consider this issue to be imlpemented.