[bug#36493] [PATCH 2/2] gnu: Remove ghc-parsec, ghc-stm, ghc-text, ghc-xhtml.

[Robert Vollmert]

> On 4. Jul 2019, at 13:28, Ricardo Wurmus <address@hidden> wrote:
> 
> 
> Hi Robert,
> 
>> I’ve just updated and rebundled them to fix the haskell packages
>> that were added to Guix in the meantime (original patch from Jun 1:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36038).
> 
> thank you for these patches.  They look good to me.  I’ll apply them in
> a moment.

Thank you!

>> Consensus last time this was discussed was that we should implicitly
>> depend on the GHC-included packages instead of re-packaging them:
>> 
>> https://lists.gnu.org/archive/html/guix-patches/2019-06/msg00000.html
> 
> I’m having second thoughts about this consensus, because I remembered
> what I did for R.  R comes with a bunch of “recommended packages” and
> they are required to run the test suite.  But instead of having the R
> package include all of these “recommended packages” I created
> “r-minimal” and one package for each of these otherwise included
> modules.
> 
> In R applications and libraries I added packages as needed, even if they
> were part of the “recommended packages”.  This was possible because we
> used “r-minimal” in the build system.
> 
> Is something like this at all possible for GHC?  Can we force GHC to
> ignore modules it includes or remove them all together?  It would be
> more elegant if Guix packages for Haskell applications each had a
> comprehensive “inputs” field without having to rely on any implicitly
> included libraries.

I’m pretty sure it’s somehow possible, but I understand the internals
of the haskell build system and GHC’s package database too poorly to
be able to say how.

Could we do something in guix like what nixpkgs does, where the dependencies
are encoded, but then “nulled” depending on the compiler version?

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-ghc-8.4.x.nix#L10

Cheers
Robert