On Thu, Mar 22, 2012 at 1:54 PM, David Terei <davidte...@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 <ig...@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 <ig...@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
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
