Changes to GHC that will expose new packages

[Duncan Coutts]

On Thu, 2012-03-22 at 23:24 -0700, David Terei wrote:
> So do we have any proposal for a way forward here? seems the options now are:
> 
> 1) Include mtl, haskeline, terminfo, utf8-string. Mark as hidden all except mtl.
> 
> 2) As above but rename all except mtl to be ghc-*
> 
> 3) Discuss including packages that provide functionality equivalent to
> above packages in haskell platform, rework ghc code to depend on those
> instead, include all packages and expose them.
> 
> 4) Fix cabal / ghc to allow ghc to depend on packages and have them
> remain truly internal
> 
> I'd be happy with any of the first 3 and particularly the first 2 as
> it minimizes the work i need to do. Long term 4 seems to be the right
> approach.


Hi David,

I'm glad that you're keen on helping address this issue. Yes it is a
problem that dependencies of GHC effectively bypass the HP process
that's designed to make sure the library APIs we expose are sensible and
supportable.

This has already happened in 7.4 with the binary package (and I'm not
happy about it).

I think the best solution would be some technical mechanism to avoid
exposing these packages by default. That way we can avoid making them
part of the HP before they are ready (or indefinitely if they're not
suitable).

The previous partial solution was the "ghc-" prefix hack. I thought that
wasn't too bad. Ian doesn't like it however. Previously ghc did ship
ghc-binary and it's true that a few people started depending on that
anyway.

Note that the package "hiding" mechanism is ignored by Cabal, and
rightly so, otherwise it would be impossible to use e.g. the ghc
package. The hiding only hides things from ghci / ghc --make in their
default usage.

Using a totally separate package db is plausible, but would mean that
the ghc package would have to be in that separate package db.

To some extent, we may of course be able to bring in some of these deps
into the HP, but it's clearly convenient for GHC to be able to use them
prior to that. E.g. I think haskeline would be quite suitable to propose
for the HP. As others have noted, utf8-string is almost certainly not
suitable since its functionality should be covered by the base + text
packages.

Duncan