Refactor parsing of hie.yaml files

[ThomasCrevoisier]

Takes care of #315

This introduces a Hie.Bios.Config.YAML module which defines datatypes a bit closer to the YAML structure.
It allows writing simpler FromJSON instances (without using CPP !) and should be equivalent to the types existing in the Hie.Bios.Config module.

[fendor]

Hi!

Since CI has a failure, can you add the failing hie.yaml to the parser-tests? If I read this correctly, should be this one: https://github.com/haskell/hie-bios/blob/master/tests/projects/failing-cabal/hie.yaml

EDIT: also rather embarrassing, we forgot to test the trivial case in the parser tests.

[ThomasCrevoisier]

@fendor all should be good now !

[fendor]

Unfortunately, the generic variant suffers currently from the issue of ignoring unknown keys. Example:

cradle:
  cabal:
    comp:
    - "exe:hie-bios"

is an invalid hie.yaml.

and currently hie-bios reports:

hie-bios: AesonException "Error in $.cradle: Not a valid Cabal configuration, following keys are allowed: component"

but with this patch, this becomes:

Config {cradle = CradleConfig {cradleDependencies = [], cradleType = Cabal {component = Nothing}}}

It successfully parses, and ignores that you mistyped or misnamed the argument.

Can we do better than that?

[ThomasCrevoisier]

Oh I see. I've got few questions on this point.

As I've seen in the test suite, empty objects are allowed right ?

Regarding unknown keys, what should be the behavior when the object we provide contains a valid config but with extra keys that we will ignore ?

Failing on missing keys is pretty straightforward, but failing on extra unwanted keys might be a bit trickier to do.

[fendor]

Regarding unknown keys, what should be the behavior when the object we provide contains a valid config but with extra keys that we will ignore ?

Until now, we threw an error message. The point being that you notice you didn't write the correct configuration and something is not right.
The idea being that subtle typos are discovered ASAP, and not just ignored.

At the moment, I think it is better if we throw an error if there are extra keys we don't know.

It is indeed trickier :/

[ThomasCrevoisier]

f2f16ec is a proposal for fixing this particular point.

The downside is that we have to duplicate a bit the keys between parsing and checking but the implementation is relatively simple.

Let me know what you think !

[fendor]

BTW, I did not forget, just didn't have time for an in-depth review (since this is important to get right). So far it looks good, and I am going to review in depth until the end of the weekend.

[ThomasCrevoisier]

Sure, absolutely no worries ! I won't be responsive this week-end, but I'll remain available to work on it next week :)

[hasufell]

Until now, we threw an error message. The point being that you notice you didn't write the correct configuration and something is not right.

This will make it hard to introduce new optional keys, because older HLS versions will now choke on that config.

I think a warning is better. cabal-install also does this:

$ cabal build
Warning: /home/hasufell/git/stack2cabal/cabal.project: Unrecognized field
'foo' on line 11

[fendor]

I see your point and did not consider this angle before. @ThomasCrevoisier Would it be hard to turn these errors into warnings?

[fendor]

As I don't want to keep you waiting, we are going to merge this as it is an improvement of the status-quo. We will create an issue for the remaining issue

[ThomasCrevoisier]

👋 Truely sorry @fendor, those past months have been quite busy and I forgot to come back to this PR 😞

Feel free to move forward with it (I don't have any simple solution in mind regarding extra keys handling unfortunately), and again, sorry for the lack of reactivity.

[fendor]

No need to apologise, life can be stressful (speaking from experience), and we all deeply appreciate the time you have spent on this!