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

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

[Robert Vollmert]

Hi,

I’d like to ask someone to look at and ideally apply these patches.

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).

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

Cheers
Robert

> On 4. Jul 2019, at 09:57, Robert Vollmert <rob@vllmrt.net> wrote:
> 
> These are ghc-8.4-bundled packages, removing to avoid build
> conflicts.
> 
> * gnu/packages/haskell.scm (ghc-parsec, ghc-stm, ghc-text): Remove.
> * gnu/packages/haskell-web.scm (ghc-xhtml): Remove.
> * gnu/packages/{agda,bioinformatics,haskell,haskell-apps,haskell-check,
> haskell-crypto,haskell-web,idris,wm}.scm: Remove dependencies on
> ghc-parsec, ghc-stm and ghc-text.

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

[Ricardo Wurmus]

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.

> 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.

--
Ricardo

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

[Robert Vollmert]

> On 4. Jul 2019, at 13:28, Ricardo Wurmus <rekado@elephly.net> 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

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

[Ricardo Wurmus]

Hi Robert,

> 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

Yes, we could do this in the haskell-build-system (automatically
removing inputs before the build is set up).  My first reaction was
“this is inelegant”, but it does have some advantages: we could rebuild
packages with other versions of GHC more easily and it would just work
without having to adjust the inputs manually.

I think this would be done in guix/build-system/haskell.scm, the
“haskell-build” procedure.  There we pass all inputs unchanged through
to build-expression->derivation.  I guess we could filter inputs right
there.

--
Ricardo