Removing GHC's dependency on Cabal
Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals: http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf As I understand it, Duncan's proposal is to take the current constellation of libraries, and just remove the dependency to Cabal from GHC and bin-package-db, duplicating data structures as necessary. ghc-pkg is now responsible for converting between Cabal's format and GHC's format. Simon suggested that this 'ghc-pkg' functionality (which specifies the database format and how to handle it) should be placed in a library of its own. So in the third graph, we have a new package ghc-db which everyone depends on. Cabal no longers shells out to ghc-pkg to modify database, instead it directly converts to ghc-db's format and then invokes library functions in the library. We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.) Cheers, Edward
Hi,
On 24 July 2014 15:56, Edward Z. Yang
We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.)
If this new proposal will allow us not to ship Cabal with GHC, then I think it's preferable to the old one. For example, Haskell Platform is often forced to use an old version of Cabal because the Cabal version is determined by the GHC version.
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
Hi,
On 24 July 2014 16:07, Joachim Breitner
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?
Cabal's policy is to support versions of GHC that are up to 3 years old, so I think this could be solved with a combination of #ifdefs and automatic testing.
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
participants (4)
-
Edward Z. Yang -
Joachim Breitner -
Mikhail Glushenkov -
Simon Peyton Jones