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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
