Changes to GHC that will expose new packages

[Mark Lentczner]

On Thu, Mar 22, 2012 at 1:54 PM, David Terei <davidterei at gmail.com> wrote:

> No they could be hidden. They would need to be included but not
> necessarily exposed if that makes a difference here.


On Thu, Mar 22, 2012 at 2:16 PM, Ian Lynagh <igloo at earth.li> wrote:
>
> Also, are you sure they aren't visible in the interfaces? e.g. you don't
> want to export anything with an InputT type, and the user won't even
> want to use mtl's 'lift' or 'liftIO' functions?
>

This would be important to ensure, though only perhaps for haskeline,
terminfo, and utf8-string.

mtl is already part of HP, so that package is not as big a concern from the
HP perspective. (I.e. moving from things HP packages up to things packaged
up with GHC isn't an interface issue, only a packaging one. And then, only
on some distros.)


On Thu, Mar 22, 2012 at 2:16 PM, Ian Lynagh <igloo at earth.li> wrote:

> We don't have a way to hide packages currently. We can mark them as
> hidden in ghc's package database, but that makes no difference as far as
> Cabal is concerned.
>

I believe the current way of handling this kind of "hiding" is to make a
duplicate of the package with "ghc-" in front of the package name, and have
GHC use that. This keeps packages GHC needs for it's own use out of the
dependency graphs of user's projects. It is important to keep the packages
GHC's external interface depends on to a minimum: Most users don't
recompile GHC, and so if they do any project that links against GHC, it
effectively pins the versions of those other packages.

I think until ghc and cabal have a working concept of internal vs.
externally visible package dependencies, package renaming is the only
effective way to isolate a package used only internally.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120322/d0e5a82b/attachment.htm>