Re: Haskel LTS 12.8.

[Timothy Sample]

Hi Again,

Timothy Sample <address@hidden> writes:

> Hello,
>
> Ricardo Wurmus <address@hidden> writes:
>
>> Hi Tim,
>>
>>> To avoid duplicating work, I wanted to let you know that I am working on
>>> updating the Haskell packages to their LTS 12.8 versions.  This will go
>>> nicely with the new GHC 8.4.3.
>>
>> Excellent!  I have a couple of new package definitions and a few minor
>> updates that I wanted to push to the master branch tomorrow.  (These
>> updates work fine with with GHC 8.0.x AFAICT, but I haven’t subjected
>> them to much testing.)
>
> There’s an issue with the new GHC.  The “--allow-newer=…” flags no
> longer work.  I can’t find any info on the Web or in any changelog.  It
> seems that nobody uses “runhaskell Setup.hs …” except for us.  Right
> now, I am working around this clumsily to avoid stalling (I am just
> patching the Cabal files).  It ought to be fixed before everything gets
> merged, though.  The best idea I’ve had so far is to update the build
> system to use the “cabal” command.  Hopefully I can find something
> simpler, though.

The change is here: <https://github.com/haskell/cabal/pull/4527>, and it
is mentioned nicely in the Cabal changelog:

    * Removed unused `--allow-newer`/`--allow-older` support from
      `Setup configure` (#4527).

If we use the “cabal” command like I proposed above, we need the
“cabal-install” package which is built with (wait for it) Cabal.  We
could add an argument like “#:cabal-install?” which when false would
cause the build system to use “runhaskell Setup.hs”.  This would let us
bootstrap “cabal-install”, but we would need to use it for every package
that “cabal-install” depends on, which is a pretty substantial set.
(This also means that all of those packages could not use
“--allow-newer”.)  I find this pretty clunky.

I’m starting to think that patching the Cabal files is not so bad after
all.  The main reason we change dependency constraints so often with
Hackage packages is because we do not use the latest constraints from
upstream.  Hackage has a Cabal file revision system separate from the
release tarballs, and it is used liberally by the Haskell community.
(In fact, it seems to cause developers to be very conservative with
their constraints, because they know they can be revised easily if
needed.)  Because we only ever see the unrevised constraints, we use
“--allow-newer” often to keep up.

If we could modify the build system or add a new downloader to use these
revisions, we would only rarely need to change the Cabal file dependency
constraints, and it would make doing it via patches much less
burdensome.

Another idea is to add an “#:allow-newer” argument to the build system,
and either use a clever regex or the Cabal parser to patch the files
automatically.

Thoughts?

>>> I am keeping the work on a WIP branch that I have here:
>>> <https://gitlab.com/samplet/guix/tree/wip-haskell>.  All the updates
>>> have commits, but there is still a lot of testing to do and build issues
>>> to resolve.  I will keep you posted.
>>
>> Shall we push that to a wip-haskell branch in the Guix repository on
>> Savannah instead?  Then we could more easily let ci.guix.info build out
>> the branch.
>
> Yes!  This is a great idea.  However, maybe it’s best for a little later
> (tomorrow or the next day).  Right now, I am fixing more than my
> computer is building.  :)
>
>> --
>> Ricardo
>
>
> -- Tim