[Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

[Niklas Hambüchen]

We just had a short discussion on #ghc, I copy-paste:

http://lpaste.net/92639

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
nh2: dcoutts_: would you mind if I open a bug to discuss this?
lemao: nh2: maybe what is needed here is a concrete proposal
lemao: nh2: so this can be discussed in more detail?
lemao: nh2: I guess a ticket would be a great start

On 06/09/13 23:52, JP Moresmau wrote:
> Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib
> and a cabal-build-simple split
> (http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That
> would solve my problem nicely (GHC could depend on cabal-lib only, that
> wouldn't have to change as often as cabal-build-simple). I don't see a
> trace of that split in 1.18, anybody knows if it's still on the map?
> And thanks everybody for the contributions, it looks I'm not the only
> one that had thought about that issue...