License and permitted use of decodeDhall. about hpack-dhall HOT 9 CLOSED

@philderbeast thanks a lot for using Hpack!

The code in this repository is in the public domain, so you can use it for whatever purpose you want ;)

I wrote this initially out of curiosity and for experimentation. That was fun, but when I look at the cost/benefit ratio I'm not convinced that it's something I want to pursue further.

Pros:

• The ability to abstract
• More obvious escaping rules

Cons:

• Even more options now when it comes to Haskell package definitions; a contributor would have to deal with .cabal, package.yaml or package.dhall depending on the package he wants to contribute to
• More space for bikeshedding when it comes to formatting stuff (leading vs trailing commas)
• When using Dhall it's more likely that you get git conflicts when rebasing/merging (yes, commas again)

Abstraction is a big thing, and I think it's valid to experiment with it. But as it stands for me the cost/benefit ratio is still not favorable. This is a very personal verdict and you are of course free to experiment.

This package is currently not widely used and I didn't do a good job in preventing bit rot. I can transfer maintainership to you if you want.

BTW: Do you currently do anything that can't be done with plain hpack. From what I saw you just include stuff. I think you can achieve the same thing with Hpack's support for defaults.

Whether it makes sense at this stage to add support for hpack-dhall to cabal2nix is up for @peti to decide. If it were me to make this decision I would probably wait until there is more significant user adoption.

from hpack-dhall.

I find hpack-dhall useful and would be happy to become a maintainer of it. I'm philderbeast on hackage.

from hpack-dhall.

With flare-timing I'm keeping both package.dhall and .cabal files in sync and in source with hpack-dhall. I format each package.dhall with;

> dhall format --inplace package.dhall

from hpack-dhall.

Do you currently do anything that can't be done with plain hpack. From what I saw you just include stuff. I think you can achieve the same thing with Hpack's support for defaults.

I hadn't seen hpack-defaults. Thanks for pointing that out as an option when wanting to set up common fields.

A dhall import can be any expression or function from any source. While I could get the same behaviour as hpack-defaults by merging sets, I can and do do more. I am using imports for;

• general defaults for common fields
• default-extensions
• passing default-extensions as -XExtensionName to hlint, see GlideAngle/flare-timing#55 (comment)
• toggling whether to have hlint test suites

from hpack-dhall.

@sol could you please add me as a maintainer for this package on hackage?

As for this repository, can you please transfer the ownership to me or add me as a collaborator?

from hpack-dhall.

Hey, sure, what is your Hackage username?

from hpack-dhall.

I'm philderbeast on hackage.

from hpack-dhall.

Added you. Please feel free to pick a license, I strongly suggest MIT or BSD3 though. Please also change the maintainer to yourself ;).

from hpack-dhall.

Thanks @sol. I've revised the package description, adding you as author and me as maintainer.

from hpack-dhall.