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@haskell.org] On Behalf Of | Joachim Breitner | Sent: 24 July 2014 15:07 | To: ghc-devs@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@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nomeata@debian.org

On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery wrote:

On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

...

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

So cabal can maintain its conceit that it supports more than just ghc.

I don't understand this as an argument against the ghc-db library, which to me also seems the simple and obvious solution. Having a ghc-db library will mean one of two options: 1. The *ghc-db* is GHC-specific and will be used by the GHC specific wrappers in Cabal: doesn't cabal already deals with each compiler differently? 2. The ghc-db is really *hs-db* and a library contract that can be reused by all haskell compilers (i.e. part of The Haskell Cabal) In both cases, the assumption is that ghc-db/hs-db should have a stable API. Now, choosing option (1) doesn't eliminate option (2). When and if there is a broad agreement across all compilers, ghc-db could become hs-db and be incorporate into The Haskell Cabal.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel