Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of dhall-to-cabal #180

Open
ocharles opened this issue Aug 11, 2019 · 9 comments
Open

The future of dhall-to-cabal #180

ocharles opened this issue Aug 11, 2019 · 9 comments

Comments

@ocharles
Copy link
Member

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?

@mitchellwrosen
Copy link

:( I'm interested in why you aren't using it anymore. Dhall syntax too verbose, the cabal file format keeps changing, or something else?

@jneira
Copy link
Collaborator

jneira commented Aug 12, 2019

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.

@freuk
Copy link

freuk commented Aug 13, 2019

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 :)

@ocharles
Copy link
Member Author

A user! I didn't know we had any of those. Are you able to share anything, or is it private work?

@ocharles
Copy link
Member Author

:( 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.

@freuk
Copy link

freuk commented Aug 13, 2019

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.

@quasicomputational
Copy link
Collaborator

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.

@jneira
Copy link
Collaborator

jneira commented Aug 29, 2019

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). 😄

@andreasabel
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants