#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