[GHC] #8244: Removing the Cabal dependency

[GHC]

#8244: Removing the Cabal dependency
-------------------------------------+------------------------------------
        Reporter:  nh2               |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by ydewit):

 This most likely asks for a minimal lib shared between GHC and Cabal and
 here is, based on previous emails/discussion, a general set of
 requirements:
  1. GHC should not depend on a specific Cabal version and shouldn't need
 to include Cabal in it's build infrastructure (Cabal should just be a pre-
 requisite tool installed in the system with a general version range for
 compatibility e.g. Cabal 1.10+)
  2. GHC should not be forced to accept specific dependencies introduced by
 Cabal (e.g. new InstalledPackageInfo parsers/etc) - this means that a
 shared lib for GHC and Cabal should be minimal.
  3. Cabal should not be constrained by the limited set of dependencies
 allowed in GHC (e.g. free to introduce whatever new parsers makes sense)
  4. Cabal should be able to add new InstalledPackageInfo fields that have
 no meaning to GHC without affecting GHC - i.e. maybe there should be a
 generic custom field that is opaque to GHC but that is still stored with
 GHC's package repo.

 In addition, I would also like to add other general comments/questions for
 discussion here:
  * where do we think this shared lib belongs to, or iow, who onws it, ghc
 or cabal?
  * Is the long term goal to have GHC as a compiler that only knows how to
 compile single packages (so dumb wrt to package resolution? Is that even
 possible?) and where the current ghc-pkg functionality is really all
 managed by Cabal?
  * Or should GHC (or any other Haskell compiler for that matter) have
 their own notion of a package, dependencies to support linking, repl,
 shared libs)?

 And finally, I would like to introduce a potential solution to this
 problem that is nothing really new considering what has already been
 discussed in the past, but describes it in a larger scope.

 The idea is to view this shared lib as an API package containing only
 interface types/functions and NO implementation. At first this API package
 would contain only one '...Packages' module with the shared
 types/functions between GHC and Cabal, but it could in the future contain
 additional modules that could make sense (parsing, name resolution,
 command line front-end, etc). With a bit of discipline, this API package
 could also be used by the Haskell-Suite project (e.g. the Haskell-Packages
 could be another implementation of the same packages API, or other haskell
 existing compilers). Cabal would then have a single, abstract way of
 interfacing with Haskell compilers for package management and adding new
 ones would not require major Cabal changes.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler