The future of dhall-to-cabal
ocharles opened this issue · comments
Hi all,
I'm not an active user of dhall-to-cabal, and I'm not even sure if it has any users. As such, I don't really feel like I want to continue maintaining this anymore. What should the future of dhall-to-cabal be? Do we upstream it to dhall-haskell? We could, but I think we should be aware of the maintenance burden. Another option is to simply leave it here - there's no reason the project has to die if I move away, but someone will need to take up some ownership.
@jneira do you use dhall-to-cabal, or just the ideas from it? @quasicomputational are you actually using dhall-to-cabal?
:( I'm interested in why you aren't using it anymore. Dhall syntax too verbose, the cabal file format keeps changing, or something else?
I am using a soft fork suited for etlas and i try my best to keep it in sync with the main repo. The integration with etlas is complete although the etlas version has not been released yet. Our idea is dhall should be the main config format for etlas, and i personally use it in all my etlas projects (and in some haskell ones too).
I think the main drawback, as you noted in dhall-lang/dhall-haskell#1189 (comment), it is to have to make the conversion manually.
Maybe dabal could fix it.
Another reason to a slow adoption could be that dhall-to-cabal would shine to maintain several (many?) projects sharing a common set of dependencies, flags, etc. For example for eta projects we have published the preferred versions of several packages to use it directly in project configs. It is harder to see its advantages trying it for one or a few not closely related projects.
I think that dhall-to-cabal in its own it is a good example of using extensively dhall-haskell as a library and a nice (imo) alternative to the devops atual main use case. Maybe it doesn't fit perfectly as a dhall-haskell subproject but it could be a last resort to keep it active.
I'm using the project actively as cabal file generation seems the most convenient way to marry complex Nix packaging with Cabal. I find that I often rely on dhall-to-cabal to overcome some of Nix, cabal2nix, or cabal's limitations, and am planning to keep doing that :)
A user! I didn't know we had any of those. Are you able to share anything, or is it private work?
:( I'm interested in why you aren't using it anymore. Dhall syntax too verbose, the cabal file format keeps changing, or something else?
I have never actually used dhall-to-cabal, beyond the dog-fooding in this repository.
It's mostly small scale use but I still reap benefits, here's one of the configurations I used,
Dhall usage is mostly for code factoring. It's a small project but the resulting cabal file is really 500 lines and has a lot of information duplication so.
https://gist.github.com/freuk/f8054097acf784a1d66fe59924817f40
One thing I did was vendor the dhall folder from dhall-to-cabal in that repository to help speed up the dev workflow.
I've not managed to use dhall-to-cabal in anger yet - two attempts have bounced off so far for various reasons, but it's still on my to-do list and I do want to get it to work.
I do intend to keep on poking at it and not letting it fall off the dependency treadmill, at a bare minimum.
I think putting it into dhall-haskell should be done with some caution because of how it complicates GHC upgrades; maybe we should do it as a last resort if we all wind up flaking.
Giving out the commit & hackage bits to @jneira and @freuk makes a lot of sense to me, since they're invested in its success.
I don't want pass the buck but being honest i feel that i don't have the knowledge and experience to be the owner of this project.
I would nominate @quasicomputational for being it precisely for the opposite reasons, if finally @ocharles doesn't change his mind now that we have user(s). 😄
This project does not build on GHC 8.8 or higher: https://matrix.hackage.haskell.org/#/package/dhall-to-cabal
Making it usable might be the first step to get users. Folks seldom bet on dead horses.