Changes to GHC that will expose new packages

[David Terei]

On 29 March 2012 15:28, Duncan Coutts <duncan.coutts at googlemail.com> wrote:
> 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.

So once I thought about the issues a little more I quickly realized
it's more complicated than I originally thought. My understanding is
that GHC includes it dependencies as it also includes the 'ghc'
library package, so any code compiled using the ghc api has to link
against GHC's dependencies.

Solving this is challenging. Just brainstorming ideas it seem you can do:

1) Statically include all of GHC's dependencies in the library (e.g
some build script hackery) so that the GHC library doesn't actually
have any dependencies. This is pretty damn ugly but would work
effectively.

2) Rename GHC's dependencies to make them unique. If we could do this
and also enforce people not depending on them this seems a pretty good
solution. We would want to establish a design requirement on the GHC
API to try to not leak dependencies so users don't need to interact
directly with ghc-binary... ect.

3) Design GHC/Cabal such that a package can have unmet dependencies.
When a user tries to use the package they will be told on the unmet
dependencies and they can then be resolved at this time. So you could
imagine GHC would include its API and a specification of its
dependencies and their bounds but not the actual libraries. First time
a user install a package that uses the GHC API or they use it
themselves the dependencies will need to be resolved. Lots of
trickiness and challenges here as you need to have some kind of
assurance about ABI compatibility. From a users point of view I quite
like it though.

4) Include dependencies but somehow segregate (e.g separate package
db's). This doens't sound great to me as to use the GHC API you are
still pulling in this segregate package db. Although I guess that's
probably fine.

5) As above but with some kind of reachability analysis so that a
compilation could include two different versions of the same package.
Ensure GHC API contains all dependencies...

Of these either 2) or 4) seem appropriate solutions. 1) is a pretty
big hack (although I wouldn't be against it but no way I want to do
the build system hacking to get that to work), while 3) and 5) require
too much engineering work and aren't necessarily better to be worth
it.

Cheers,
David

>
> Duncan
>