search

dhall-lang / dhall-to-cabal

Compile Dhall expressions to Cabal files
MIT License
100 stars 19 forks source link

Add dabal (name subject to bike shedding) #123

Open ocharles opened 6 years ago

ocharles commented 6 years ago

It's a little tedious having to go from .dhall to .cabal and then to use cabal. We could add dabal, which is a wrapper around cabal. It would generate the .cabal file and then run cabal commands on it. It might be possible to do this without generating a file at all, which would be nice!

quasicomputational commented 6 years ago

For single-package, projects, this could be done as a simple wrapper around cabal-install; it should be like 3 lines of shell, including the shebang. Might I suggest we follow hpack's lead and have a consistent name for the input Dhall, like package.dhall, rather than naming it after the package name? #113 is also relevant here.

I think haskell/cabal#3552 and haskell/cabal#630 will mean that we do have to generate a .cabal file, but I'm not 100% sure.

I don't think this can be done for multi-package projects (or anything involving a non-trivial cabal.project) given that cabal-install doesn't have an officially sanctioned public API - not even for reading .project files. haskell/cabal#1597 and haskell/cabal#5476 are discussions about exposing the guts of cabal-install for any consumers brave enough to endure the risk of breakage, but I'm not terribly hopeful, not least because the .project parsing code in cabal-install is a bit convoluted and wouldn't be the most convenient API for general consumption anyway...

Semi-relatedly, I've been kicking around the idea of dhall-to-cabal integration with Stack. Stack already knows about hpack and its package.yaml and will automatically generate the .cabal files as needed without a separate step. Presumably, we could get the same treatment, but I also think that dhall-to-cabal is probably not mature enough yet for inclusion in the mainline. At the very least, the type-checking performance still isn't good enough...