Re: heads-up: Haskell updates

[Timothy Sample]

Ricardo Wurmus <address@hidden> writes:

>> Based on your earlier suggestion, I played around with removing all the
>> packages that GHC provides.  I made the same change to ghc-mtl on
>> core-updates, and it allows me to build ghc-resourcet.
> […]
>> Is this too drastic?  I could rebase on top of your ghc-mtl changes and
>> submit a patch if you think its OK.
>
> Not too drastic.  This is exactly what I had hoped for :)
>
> Thank you for making the effort.  A patch on top of latest core-updates
> / master would be very welcome.

I sent the patch.  It’s bug #30501.  (The most complicated part was the
changelog; I hope it’s OK!)

> Now, how do we prevent this in the future?  Can we modify “guix lint” to
> warn about these cases?  Can we also change the hackage importer to
> keep these packages out of the inputs of generated package definitions?

I can think of two approaches.

We could follow the style of Hackage and force everything to reference
the base libraries.  To make this work, we would have to make builds
fail if they don’t reference a base library that they need.  Maybe
there’s a way to hide the base libraries in the Haskell build system,
and use packages to expose them.  The major downside to this is adding a
“ghc-base” input to every Haskell package (and “ghc-binary” to a bunch,
etc.).  The upside is that it is more intuitive: the inputs look more
like Hackage, and you could try new versions of the base libraries using
standard Guix tools like:

    $ guix package -i ghc-pandoc \
        --with-input=ghc-transformers=ghc-transformers-new

(This would update all the dependencies, too, leaving the GHC-provided
library hidden and only exposing the new library, thus avoiding all the
conflicting version problems.)

We would have to make sure that “guix package -i ghc” still provides the
libraries, though, to save people a lot of confusion.

The second approach would be to leave everything implicit, and add notes
everywhere not to break things (in the docs, the linter, and the
importer).  I guess we would have to be careful when updating GHC in
case it adopts new base libraries.  The appeal of this approach is that
it is basically what we just did, so it’s done modulo the changes to the
linter and importer.

Personally, I prefer the first approach even though it’s a bit of a
radical departure.  It feels like it fits more both with Guix and
Haskell.  I also think that most Haskell people coming to Guix would
just understand it without any extra explanation.  Updating every single
Haskell package is a bit daunting :S.  It’s something I’m willing to
look at, though.

What do you think?  I’m happy to look at the linter and importer, too.
I would like to package “git-annex”, so making the Haskell stuff a
little nicer is only a minor detour towards that goal (last I checked, I
will have to import a lot of packages yet).


-- Tim