[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 nh2):

 A follow-up discussion from #ghc:

 {{{
 dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal
 specifies a compiler-independent package registration format. GHC uses it
 in its external interface (and internally too). It uses the Cabal lib for
 the parser+printer because it's easier than making its own and keeping up
 with spec changes..
 dcoutts_: type+parser+printer
 nh2: dcoutts_: would it still not be easier to make this package database
 specification a separate thing that both ghc and cabal can depend on? It
 seems to me that this would be much less a moving target than Cabal-the-
 build-system is
 dcoutts_: nh2: what does make sense is to split the Cabal lib into the
 Distribution.* bits and the Distribution.Simple.* bits
 dcoutts_: nh2: it's not a natural split
 hvr: nh2: btw, a related thread: http://www.haskell.org/pipermail/ghc-
 devs/2013-March/000800.html
 dcoutts_: nh2: there's a lot of types shared between the .cabal format and
 the InstalledPackageInfo type
 dcoutts_: as well as parser + printer infrastructure
 dcoutts_: nh2: it makes sense to keep that all together, that's the
 Distribution.* stuff
 dcoutts_: as I said, what does make sense to split (it's been deliberately
 kept mostly-separate) is the Distribution.Simple.* part
 dcoutts_: nh2: and we need a parser for that part, that's the dependency
 that's annoying
 thoughtpolice: so yes, i'm going to look into it today if at all possible
 nh2: dcoutts_: that makes sense. ghc does not depend on
 Distribution.PackageDescription either, right?
 dcoutts_: nh2: right, it doesn't need the source package type
 (PackageDescription), just the installed package type
 (InstalledPackageInfo)
 dcoutts_: nh2: but splitting these into different packages would not buy
 us much and it's not a natural split
 nh2: leaving away Distribution.Simple.*, the remaining part is already so
 small that it indeed looks like a small enough interface
 dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it
 cabal-build-simple) could build with an earlier core part (lets call it
 cabal-lib) (in his request in http://www.haskell.org/pipermail/haskell-
 cafe/2013-September/108746.html)
 dcoutts_: nh2: and doesn't help me with my parser problems, we still
 cannot depend on a decent parser combinator lib
 dcoutts_: still have to use the crappy ReadP
 nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format
 itself, right? Not sure if that should be part of the package DB spec, it
 changes more often and ghc can't make use of it
 nh2: why is it that you cannot depend on something better?
 dcoutts_: nh2: because ghc cannot depend on parsec easily
 dcoutts_: because it pulls in too many other things
 dcoutts_: the ghc devs objected to my suggestion
 dcoutts_: nh2: that's true but what does it really buy us if they're in
 separate packages? We still cannot guarantee to support JP M's request
 dcoutts_: e.g. in the switch to 1.18, there have been enough changes that
 we'd need the latest version of the InstalledPackageInfo
 hvr: dcoutts_: ...seems you have to explain that again everytime somebody
 brings it up =)
 nh2: dcoutts_: but do I not understand it right that if you put
 PackageDescription not into cabal-lib and only in Cabal, Cabal could
 actually depend on a proper parser since GHC doesn't depend on it any
 more?
 dcoutts_: nh2: it's not a monolithic parser
 dcoutts_: nh2: we have that Text class
 dcoutts_: with the combinator parsers for all the various types used in
 .cabal and installed package files
 dcoutts_: these types + parser/printer infrastructure are shared between
 the source and installed package files
 dcoutts_: so even if we split it, we still have the problem of needing a
 parser lib
 lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of
 splitting Distribution.Simple at the same time that this GHC dependency on
 cabal is really problematic for all the reasons already discussed
 dcoutts_: lemao: I don't think splitting it would fix that
 lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to have
 GHC own their own internal package info impl so Cabal and GHC can go their
 separate ways
 dcoutts_: you'd still have ghc depending on this smaller part, and Cabal
 /cabal-install would still depend on (usually) the latest version of that
 dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a
 private dep of ghc) because ghc api exposes the InstalledPackageInfo type
 dcoutts_: it's not a private dependency of the ghc api package, it's a
 public dependency
 lemao: dcoutts_: I guess what I meant is that ghc-pkg package
 format/parser/etc would be a complete fork
 dcoutts_: which then means you cannot pass the InstalledPackageInfo from
 ghc api functions to anything else
 lemao: dcoutts_: at the same time that there are issues with the split
 there are real issues witht he current status quo
 dcoutts_: as well as meaning it'd get out of sync
 nh2: dcoutts_: InstalledPackageInfo looks like a very
 simple/straightforward type though
 dcoutts_: nh2: on it's own, but it uses a bunch of other types + their
 parsers+printers
 dcoutts_: nh2: and are we really saying that we could always work with old
 versions of this type, that we'd never need to depend on the latest
 version in the latest version of Cabal?
 dcoutts_: because if not, then we gain nothing
 lemao: dcoutts_, nh2: real question here, how often does the package info
 that matters for ghc actually changed in the past?
 dcoutts_: lemao: it does change occasionally
 dcoutts_: and it will change again
 dcoutts_: we have changes pending
 lemao: dcoutts_, nh2: I can see how most of the drivers for these changes
 come from cabal
 nh2: dcoutts_: I can't see many other types, there are only two: License
 (a simple enum) and Version. Everything else is String/Bool
 dcoutts_: nh2: PackageName, PackageId etc
 nh2: dcoutts_: are both string newtypes
 dcoutts_: nh2: but note also that it uses the same parser infrastructure
 }}}

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