Request for merging "haskell-team" branch

  • Done
  • quality assurance status badge
Details
2 participants
  • Lars-Dominik Braun
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Lars-Dominik Braun
Severity
normal
L
L
Lars-Dominik Braun wrote on 8 Jun 08:36 +0200
(address . guix-patches@gnu.org)
ZmP75URLQIW9AmfL@noor.fritz.box
Hi,

I would like to merge the haskell-team branch. It contains a big quality
of life improvement for Haskell developers, by allowing cabal-install
to work with Guix-provided packages. Apart from that GHC was upgraded
to version 9.2.8 and Stackage was upgraded to the corresponding version
20.26.

Lars
L
L
Liliana Marie Prikler wrote on 12 Jun 19:12 +0200
a548015e6d6d93a1d34f097cf47ec24dab397ea9.camel@gmail.com
Hi Lars,

Am Samstag, dem 08.06.2024 um 08:36 +0200 schrieb Lars-Dominik Braun:
Toggle quote (6 lines)
> Hi,
>
> I would like to merge the haskell-team branch. It contains a big
> quality of life improvement for Haskell developers, by allowing
> cabal-install to work with Guix-provided packages. Apart from that
> GHC was upgraded to version 9.2.8
So far LGTM.

Toggle quote (1 lines)
> and Stackage was upgraded to the corresponding version 20.26.
That commit really lacks a readable message, though.

Further, I think our work is far from done; just attempting to update
pandoc has me yak-shaving the depths of haskell-*.scm with no end in
sight. If that's our only haskell application, we're in luck, but I
fear there might be more.

Cheers
L
L
Lars-Dominik Braun wrote on 12 Jun 21:53 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 71427@debbugs.gnu.org)
Zmn8wAzB17mD0ajN@noor.fritz.box
Hi,

Toggle quote (3 lines)
> > and Stackage was upgraded to the corresponding version 20.26.
> That commit really lacks a readable message, though.

I know it does not conform to Guix standards. What do you suggest? One
commit per package is not feasible.

Toggle quote (5 lines)
> Further, I think our work is far from done; just attempting to update
> pandoc has me yak-shaving the depths of haskell-*.scm with no end in
> sight. If that's our only haskell application, we're in luck, but I
> fear there might be more.

Is Haskell-world, you can’t just update pandoc. Pandoc is part of the
curated set of Stackage packages and those *must not* be updated,
unless there is a new Stackage release which matches our GHC compiler
(there is not). Otherwise, well, dependency hell…

I’m also pushing a fix for ghc-aeson, which should fix most other
packages as well.

Lars
L
L
Liliana Marie Prikler wrote on 13 Jun 06:23 +0200
(name . Lars-Dominik Braun)(address . lars@6xq.net)(address . 71427@debbugs.gnu.org)
2529fa59d58eeaade2465dc654a3c5ffb380a12a.camel@gmail.com
Am Mittwoch, dem 12.06.2024 um 21:53 +0200 schrieb Lars-Dominik Braun:
Toggle quote (7 lines)
> Hi,
>
> > >  and Stackage was upgraded to the corresponding version 20.26.
> > That commit really lacks a readable message, though.
>
> I know it does not conform to Guix standards. What do you suggest?
> One commit per package is not feasible.
I think mentioning each file and package would be good enough™.
If parts can be split off into more commits, that's fine, but
everything that needs to be bumped along with the variable, needs to be
bumped.

Toggle quote (9 lines)
> > Further, I think our work is far from done; just attempting to
> > update pandoc has me yak-shaving the depths of haskell-*.scm with
> > no end in sight.  If that's our only haskell application, we're in
> > luck, but I fear there might be more.
>
> Is Haskell-world, you can’t just update pandoc. Pandoc is part of the
> curated set of Stackage packages and those *must not* be updated,
> unless there is a new Stackage release which matches our GHC compiler
> (there is not). Otherwise, well, dependency hell…
Is there any other way to get pandoc-3.2 then? I have a package that
appears to depend on that.
Perhaps we could do -next variants, but there'd still be a lot of them.

Toggle quote (2 lines)
> I’m also pushing a fix for ghc-aeson, which should fix most other
> packages as well.
Neat.

Cheers
L
L
Lars-Dominik Braun wrote on 14 Jun 08:24 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 71427@debbugs.gnu.org)
ZmviM-1uqdhVskyq@noor.fritz.box
Hi,

Toggle quote (5 lines)
> I think mentioning each file and package would be good enough™.
> If parts can be split off into more commits, that's fine, but
> everything that needs to be bumped along with the variable, needs to be
> bumped.

I mean, if a 250-line-ish long, auto-generated commit message is
okay…?[1] It’s usefulness is disputable, but I can’t do this by
hand for ~230 packages.

Toggle quote (4 lines)
> Is there any other way to get pandoc-3.2 then? I have a package that
> appears to depend on that.
> Perhaps we could do -next variants, but there'd still be a lot of them.

You could try a fresh import with `guix import hackage -r pandoc`, but
you’ll probably run into issues with packages requiring more recent
GHC-provided packages. Then you can either try to build a newer GHC[2]
or download the entire Hackage database and use a solver to find a
combination of packages that works with our current GHC (i.e. what
Stackage does by hand, afaik).

Toggle quote (4 lines)
> > I’m also pushing a fix for ghc-aeson, which should fix most other
> > packages as well.
> Neat.

This is done now. Let’s convince everyone else that skipping the merge
queue is fine in this case…

Lars

[1] git show | sed -nre 's#^\+\+\+ b/(.*)#* \1#gp; s/^@@.*\(define-public (.*)/(\1): Update./gp' | uniq
L
L
Liliana Marie Prikler wrote on 14 Jun 18:54 +0200
(name . Lars-Dominik Braun)(address . lars@6xq.net)(address . 71427@debbugs.gnu.org)
55ee8c7176345a9ff0866c2f5d5006f573e0bac6.camel@gmail.com
Am Freitag, dem 14.06.2024 um 08:24 +0200 schrieb Lars-Dominik Braun:
Toggle quote (10 lines)
> Hi,
>
> > I think mentioning each file and package would be good enough™.
> > If parts can be split off into more commits, that's fine, but
> > everything that needs to be bumped along with the variable, needs
> > to be bumped.
>
> I mean, if a 250-line-ish long, auto-generated commit message is
> okay…?[1] It’s usefulness is disputable, but I can’t do this by
> hand for ~230 packages.
Well, yes, we do have a script to do that, and it'd be an improvement
over what we already have. Maybe review the output, but that'

Toggle quote (11 lines)
> > Is there any other way to get pandoc-3.2 then?  I have a package
> > that appears to depend on that.
> > Perhaps we could do -next variants, but there'd still be a lot of
> > them.
>
> You could try a fresh import with `guix import hackage -r pandoc`,
> but you’ll probably run into issues with packages requiring more
> recent GHC-provided packages. Then you can either try to build a
> newer GHC[2] or download the entire Hackage database and use a solver
> to find a combination of packages that works with our current GHC
> (i.e. what Stackage does by hand, afaik).
I've started doing that, but I get a conflict with a core package,
meaning that I'd need GHC 9.4 or newer. We probably ought to look into
making that the current GHC to get a fresher Stackage.

Toggle quote (6 lines)
> > > I’m also pushing a fix for ghc-aeson, which should fix most other
> > > packages as well.
> > Neat.
>
> This is done now. Let’s convince everyone else that skipping the
> merge queue is fine in this case…
Note that I have little experience with Haskell otherwise, so whatever
I say, it'll probably not be too convincing.

Cheers
L
L
Lars-Dominik Braun wrote on 29 Jun 08:58 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 71427-done@debbugs.gnu.org)
Zn-woUwz_52Hxfta@noor.fritz.box
Hi,

the branch has been merged into master.

Lars
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 71427@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 71427
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch