Nickel to Cabal

[sir4ur0n]

I am creating this issue in the name of @amesgen as we had a conversation on that topic recently.
I am sure @amesgen will have more input, and probably great ideas, on the kind of solution we may want if we decide to move forward with this.

@amesgen obviously feel free to edit or correct anything I write 😄

Is your feature request related to a problem? Please describe.
@amesgen currently works on a Haskell project with various packages and various Cabal files.
Currently the various Cabal files must use some shared parts (e.g. a common set of GHC default extensions, dependencies or dependency versions, flags, etc.).
So far they just duplicate these parts, but as you can imagine, this is brittle (and in practice inconsistent).
Cabal apparently does not provide a convenient way to share this kind of things across Cabal files.

Describe the solution you'd like
A convenient way to express Cabal files in Nickel, and a Nickel-to-Cabal converter.

Describe alternatives you've considered
Apparently dhall-to-cabal was considered/prototyped but they met the following shortcomings:

• need to add Dhall type annotations in many/most places as the type inference often gave up/failed to correctly infer types
• dhall-to-cabal seems abandoned: the last non-automatic commit dates back to 3 years ago

[thufschmitt]

Would this yield a substantial advantage over hpack?

[sir4ur0n]

To the best of my knowledge Hpack only provides a YAML API. That is:

• no functions, though some basic kinds of "functions" are supported: anchors, aliases, merge keys
• no static types
• no contracts
• no import from another file

Typically I don't think Hpack is able to address the use case I mentioned in the first message (several files with common parts)

[amesgen]

Thanks for writing this up @sir4ur0n! Just a few additional remarks:

• Upon second look, hpack actually has support for including stuff from another file: https://github.com/sol/hpack#not-repeating-yourself using the custom !include:

  Still, this is obviously a much weaker abstraction mechanism than actual functions.

• Still, hpack is YAML, and replacing complex use cases of YAML is one of the prime targets of Nickel AFAIK.

• Very funnily, there even exists the (decently maintained) hpack-dhall to generate hpack from Dhall, which nicely demonstrates that people are not satisfied with hpack 😄

• Another use case for Dhall/Nickel⟶Cabal: "Updateable templates": Usually, when people create a new Cabal project, they generate it via cabal init or via sth more sophisticated like summoner. A disadvantage is that you can't easily pull in improvements to the template (better choice of GHC warnings etc.) without completely regenerating it. OTOH, if the template consists of a remote Nickel file and one only adapts minor project-specific details, updating is trivial.

  This might be useful both for beginners and for people maintaining many libraries wanting to share best practices.

[amesgen]

Also, I think all bullet points in dhall-to-cabal's "Why?" section should also apply for a hypothetical nickel-to-cabal: https://github.com/dhall-lang/dhall-to-cabal/#why