Removing GHC's dependency on Cabal

[Simon Peyton Jones]

The way I am thinking of it is this. In "Simon's proposal" in
  http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf
the ghc-db library is simply a Haskell library that gives a programmatic way to interact with GHC's installed package database(s). GHC needs that.  ghc-pkg needs that.  cabal needs that.  There should be one thing that supplies it.

Cabal currently shells out to ghc-pkg, which in turn mandates a special file format (the .conf file) that Cabal uses to communicate its wishes to ghc-pkg.  This needs syntax, a parser, a pretty printer, and is, to all intents and purposes  just as stable, or unstable, as a Haskell API to ghc-db would be.

To me it seems simple and obvious!  Why are we going round the houses to do something so simple?

Simon


| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 24 July 2014 15:07
| To: ghc-devs at haskell.org
| Cc: cabal-devel
| Subject: Re: Removing GHC's dependency on Cabal
| 
| Hi,
| 
| 
| Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang:
| > We were wondering if there was any reason to prefer the former
| > situation over the latter.
| 
| One way to decide that is to ask “What is the more stable interface”?
| I.e. under what circumstances will upgrading Cabal require upgrading
| packages depended upon by ghc.
| 
| So while Duncan’s Proposal has no such dependency, in Simon’s proposal
| there is one. Will ghc-db’s interface be stable enough that the Cabal
| developers will be happy to build against a very old version of it?
| 
| Greetings,
| Joachim
| 
| 
| --
| Joachim “nomeata” Breitner
|   mail at joachim-breitner.de • http://www.joachim-breitner.de/
|   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
|   Debian Developer: nomeata at debian.org