Re: updating many haskell packages

[Troy Sankey]

Quoting Troy Sankey (2017-02-18 12:40:15)
> There is one more problem, and it is not a minor problem...
> 
> --- cut here ---
> $ du -hs tmp/all-cabal-files
> 862Mtmp/all-cabal-files
> $ du -hs tmp/all-cabal-files/.git
> 140Mtmp/all-cabal-files/.git
> $ echo '862 - 140' | bc
> 722
> --- cut here ---
> 
> The filesize of the package output will be 722 MiB.  We could prune it
> of all the unrelated versions according to the stackage LTS, but this
> starts to get complicated and error-prone...

On second thought, this is not too much of an issue since
ghc-all-cabal-files would only be an implicit *native* input.
Bystanders who install ghc-old-time (or any other package with a revised
cabal file) from a guix substitute will not need to download
ghc-all-cabal-files.

Troy


signature.asc
Description: signature

Re: updating many haskell packages

[Federico Beffa]

On Sat, Feb 18, 2017 at 6:40 PM, Troy Sankey  wrote:
> Quoting Federico Beffa (2017-02-18 04:43:51)
>> On Fri, Feb 17, 2017 at 6:47 PM, Troy Sankey  wrote:
>> > Forgive me if my understanding of build systems in Guix is flawed, but
>> > let me explain my idea with more detail:
>> >
>> > First, make a data-only package called "ghc-all-cabal-files" containing
>> > the checkout of a specific commit of the all-cabal-files repository from
>> > github.  We can periodically update this package, but there is no
>> > traditional "release"---we just keep pulling the HEAD of the hackage
>> > branch.  This package would then act as a helper package for the haskell
>> > build system---every haskell package should implicitly use this package
>> > as input.  Then we can write a post-unpack phase for the
>> > haskell-build-system which updates the unpacked .cabal file iff it finds
>> > a newer .cabal file in ghc-all-cabal-files (we know how to determine if
>> > the cabal file is newer: it will have a higher "x-revision" value, or
>> > that key will merely exist).
>> >
>> > One problem I have not fully solved is the technical debt associated
>> > with keeping the proposed ghc-all-cabal-files package up-to-date.  I
>> > believe updating it would require all haskell packages to be rebuilt.
>> > We could create a build system argument called use-newest-cabal-file to
>> > toggle the feature, in which case we would only switch it to #t if we
>> > already know the .cabal file to be stale.  Then only a small subset of
>> > packages would need to be rebuilt, and there is less technical debt than
>> > the current solution which involves monkey-patching every cabal file
>> > that needs it.
>>
>> My worry with this approach is that every time that a single cabal
>> file in 'ghc-all-cabal-files' is updated all packages will fail to
>> build (the implicit input will fail). Given that there are several
>> thousands of cabal files, I suspect that this could occur quite often.
>
> Can you elaborate on how all packages will fail to build?

I was thinking that the 'ghc-all-cabal-files' would come from a
released tar file that would change and therefore the hash would not
match.  However, as you mentioned, the package would really come from
a git checkout and would therefore not become unavailable.

My bad, sorry.

Fede

Re: updating many haskell packages

[Troy Sankey]

Quoting Federico Beffa (2017-02-18 04:43:51)
> On Fri, Feb 17, 2017 at 6:47 PM, Troy Sankey  wrote:
> > Forgive me if my understanding of build systems in Guix is flawed, but
> > let me explain my idea with more detail:
> >
> > First, make a data-only package called "ghc-all-cabal-files" containing
> > the checkout of a specific commit of the all-cabal-files repository from
> > github.  We can periodically update this package, but there is no
> > traditional "release"---we just keep pulling the HEAD of the hackage
> > branch.  This package would then act as a helper package for the haskell
> > build system---every haskell package should implicitly use this package
> > as input.  Then we can write a post-unpack phase for the
> > haskell-build-system which updates the unpacked .cabal file iff it finds
> > a newer .cabal file in ghc-all-cabal-files (we know how to determine if
> > the cabal file is newer: it will have a higher "x-revision" value, or
> > that key will merely exist).
> >
> > One problem I have not fully solved is the technical debt associated
> > with keeping the proposed ghc-all-cabal-files package up-to-date.  I
> > believe updating it would require all haskell packages to be rebuilt.
> > We could create a build system argument called use-newest-cabal-file to
> > toggle the feature, in which case we would only switch it to #t if we
> > already know the .cabal file to be stale.  Then only a small subset of
> > packages would need to be rebuilt, and there is less technical debt than
> > the current solution which involves monkey-patching every cabal file
> > that needs it.
> 
> My worry with this approach is that every time that a single cabal
> file in 'ghc-all-cabal-files' is updated all packages will fail to
> build (the implicit input will fail). Given that there are several
> thousands of cabal files, I suspect that this could occur quite often.

Can you elaborate on how all packages will fail to build?

Also, my hope is that with the toggle switch 'use-newest-cabal-file' we
do not have to make ghc-all-cabal-files an implicit input for all
haskell packages, only a few.

> Maybe another approach could be: when we update the GHC packages we
> follow a specific Stackage release. If a package tar includes an old
> cabal file, we enable a 'jailbreak' flag such that the build system
> clears version bounds. This of course relies on the fact that Stackage
> verified that this is fine.

What you describe is almost what I mean.  It is a fine alternative
solution, and I would be open to implementing this for the immediate
term.

My approach implies that we use Stackage LTS, but instead of "jailbreak"
use "use-newest-cabal-file" since the newer cabal file often will
include those relaxed version bounds, so the effect is almost the same.
The newer cabal file may also contain other changes unrelated to
dependency version bounds [0] and those changes are implicitly verified
by Stackage LTS which also uses newer cabal files.  In fact, by not
using the updated cabal files, we are essentially diverging from the
Stackage LTS.

Remember, all-cabal-files tracks cabal revisions for every package
version.  If Stackage LTS references an old version of a haskell
package, then we can still find the "latest" cabal file for that old
version of the package in all-cabal-files.

There is one more problem, and it is not a minor problem...

--- cut here ---
$ du -hs tmp/all-cabal-files
862Mtmp/all-cabal-files
$ du -hs tmp/all-cabal-files/.git
140Mtmp/all-cabal-files/.git
$ echo '862 - 140' | bc
722
--- cut here ---

The filesize of the package output will be 722 MiB.  We could prune it
of all the unrelated versions according to the stackage LTS, but this
starts to get complicated and error-prone...

Troy

[0] 
https://www.haskell.org/cabal/users-guide/developing-packages.html#build-information


signature.asc
Description: signature

Re: updating many haskell packages

[Federico Beffa]

On Fri, Feb 17, 2017 at 6:47 PM, Troy Sankey  wrote:
> Quoting Federico Beffa (2017-02-17 03:00:04)
>> On Wed, Feb 15, 2017 at 8:31 PM, Troy Sankey  wrote:
>> > Quoting Troy Sankey (2017-02-06 16:00:29)
>> >> Quoting Federico Beffa (2017-02-06 15:34:47)
>> >> > I would consider a discrepancy between a cabal file on Hackage and the
>> >> > actual cabal file included in a tar archive a bug.  It may be helpful
>> >> > to report it to the author.
>> >>
>> >> I found this issue on the hackage github:
>> >>
>> >> https://github.com/haskell/hackage-server/issues/503
>> >>
>> >> It looks like it's a feature of hackage and/or cabal to allow multiple
>> >> revisions of cabal files per tarball release.  IIUC, the `cabal get`
>> >> utility takes care of automatically updating the cabal file to the
>> >> latest revision.
>> >>
>> >> I'll have to look more into this later.
>> >
>> > Indeed the .cabal files can be revised between releases.  Somehow the
>> > new revisions get pushed to the all-cabal-files repository [0] with an
>> > additional "x-revision" key [1], and Hackage picks up the new cabal
>> > file.  The `cabal` and `stack` utilities substitute the .cabal file from
>> > the release tarball with the revised .cabal file from Hackage if it is
>> > newer.
>> >
>> > In theory, anything in the .cabal file could be modified, not just
>> > dependency bounds.  I think guix should use the updated .cabal files for
>> > better consistency with the rest of the haskell ecosystem, and also for
>> > less per-package maintenance cost.
>> >
>> > How can guix adapt?  Should we somehow incorporate the all-cabal-files
>> > repository in the haskell build system, adding a post-unpack phase to
>> > substitute the entire .cabal file?
>>
>> Packages are build in isolated environments without network.
>> Therefore it's not possible to access Hackage with a phase of the
>> build system.  Even if it were possible it would be undesirable
>> because it would make things non reproducible.
>>
>> Files not included in the tar can be added as origin inputs to a
>> package definition (see the testsuite for GHC in the ghc package).
>> However, they are verified with hashes. Any change to those files will
>> break the package.
>>
>> Fede
>
> Forgive me if my understanding of build systems in Guix is flawed, but
> let me explain my idea with more detail:
>
> First, make a data-only package called "ghc-all-cabal-files" containing
> the checkout of a specific commit of the all-cabal-files repository from
> github.  We can periodically update this package, but there is no
> traditional "release"---we just keep pulling the HEAD of the hackage
> branch.  This package would then act as a helper package for the haskell
> build system---every haskell package should implicitly use this package
> as input.  Then we can write a post-unpack phase for the
> haskell-build-system which updates the unpacked .cabal file iff it finds
> a newer .cabal file in ghc-all-cabal-files (we know how to determine if
> the cabal file is newer: it will have a higher "x-revision" value, or
> that key will merely exist).
>
> One problem I have not fully solved is the technical debt associated
> with keeping the proposed ghc-all-cabal-files package up-to-date.  I
> believe updating it would require all haskell packages to be rebuilt.
> We could create a build system argument called use-newest-cabal-file to
> toggle the feature, in which case we would only switch it to #t if we
> already know the .cabal file to be stale.  Then only a small subset of
> packages would need to be rebuilt, and there is less technical debt than
> the current solution which involves monkey-patching every cabal file
> that needs it.

My worry with this approach is that every time that a single cabal
file in 'ghc-all-cabal-files' is updated all packages will fail to
build (the implicit input will fail). Given that there are several
thousands of cabal files, I suspect that this could occur quite often.

Maybe another approach could be: when we update the GHC packages we
follow a specific Stackage release. If a package tar includes an old
cabal file, we enable a 'jailbreak' flag such that the build system
clears version bounds. This of course relies on the fact that Stackage
verified that this is fine.

Regards,
Fede

Re: updating many haskell packages

[Troy Sankey]

Quoting Federico Beffa (2017-02-17 03:00:04)
> On Wed, Feb 15, 2017 at 8:31 PM, Troy Sankey  wrote:
> > Quoting Troy Sankey (2017-02-06 16:00:29)
> >> Quoting Federico Beffa (2017-02-06 15:34:47)
> >> > I would consider a discrepancy between a cabal file on Hackage and the
> >> > actual cabal file included in a tar archive a bug.  It may be helpful
> >> > to report it to the author.
> >>
> >> I found this issue on the hackage github:
> >>
> >> https://github.com/haskell/hackage-server/issues/503
> >>
> >> It looks like it's a feature of hackage and/or cabal to allow multiple
> >> revisions of cabal files per tarball release.  IIUC, the `cabal get`
> >> utility takes care of automatically updating the cabal file to the
> >> latest revision.
> >>
> >> I'll have to look more into this later.
> >
> > Indeed the .cabal files can be revised between releases.  Somehow the
> > new revisions get pushed to the all-cabal-files repository [0] with an
> > additional "x-revision" key [1], and Hackage picks up the new cabal
> > file.  The `cabal` and `stack` utilities substitute the .cabal file from
> > the release tarball with the revised .cabal file from Hackage if it is
> > newer.
> >
> > In theory, anything in the .cabal file could be modified, not just
> > dependency bounds.  I think guix should use the updated .cabal files for
> > better consistency with the rest of the haskell ecosystem, and also for
> > less per-package maintenance cost.
> >
> > How can guix adapt?  Should we somehow incorporate the all-cabal-files
> > repository in the haskell build system, adding a post-unpack phase to
> > substitute the entire .cabal file?
> 
> Packages are build in isolated environments without network.
> Therefore it's not possible to access Hackage with a phase of the
> build system.  Even if it were possible it would be undesirable
> because it would make things non reproducible.
> 
> Files not included in the tar can be added as origin inputs to a
> package definition (see the testsuite for GHC in the ghc package).
> However, they are verified with hashes. Any change to those files will
> break the package.
> 
> Fede

Forgive me if my understanding of build systems in Guix is flawed, but
let me explain my idea with more detail:

First, make a data-only package called "ghc-all-cabal-files" containing
the checkout of a specific commit of the all-cabal-files repository from
github.  We can periodically update this package, but there is no
traditional "release"---we just keep pulling the HEAD of the hackage
branch.  This package would then act as a helper package for the haskell
build system---every haskell package should implicitly use this package
as input.  Then we can write a post-unpack phase for the
haskell-build-system which updates the unpacked .cabal file iff it finds
a newer .cabal file in ghc-all-cabal-files (we know how to determine if
the cabal file is newer: it will have a higher "x-revision" value, or
that key will merely exist).

One problem I have not fully solved is the technical debt associated
with keeping the proposed ghc-all-cabal-files package up-to-date.  I
believe updating it would require all haskell packages to be rebuilt.
We could create a build system argument called use-newest-cabal-file to
toggle the feature, in which case we would only switch it to #t if we
already know the .cabal file to be stale.  Then only a small subset of
packages would need to be rebuilt, and there is less technical debt than
the current solution which involves monkey-patching every cabal file
that needs it.

Troy


signature.asc
Description: signature

Re: updating many haskell packages

[Ricardo Wurmus]

Troy Sankey  writes:

> Quoting Federico Beffa (2017-02-06 03:13:16)
>> On Mon, Feb 6, 2017 at 9:03 AM, Federico Beffa  wrote:
>> 
>> > (ii) The latest LTS still uses GHC 8.0.1.  I'm not sure if this is
>> > because of some real problem (GHC 8.0.2 introduces some
>> > incompatibilities) or if it is because changing things takes time.
>> 
>> Looks like LTS8 is on its way http://lwm.github.io/stackage-8.0.2/
>
> Stackage LTS 8.0 has been released:
>
> https://www.stackage.org/lts-8.0
>
> In the coming days, I'll work to make all our current haskell packages
> (and my additions) converge to LTS 8.0.  I may backport the stackage
> importer [0] if I need to, but I don't expect that it will be required.

Excellent!  Thank you for trying to tackle this!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: updating many haskell packages

[Federico Beffa]

On Wed, Feb 15, 2017 at 8:31 PM, Troy Sankey  wrote:
> Quoting Troy Sankey (2017-02-06 16:00:29)
>> Quoting Federico Beffa (2017-02-06 15:34:47)
>> > I would consider a discrepancy between a cabal file on Hackage and the
>> > actual cabal file included in a tar archive a bug.  It may be helpful
>> > to report it to the author.
>>
>> I found this issue on the hackage github:
>>
>> https://github.com/haskell/hackage-server/issues/503
>>
>> It looks like it's a feature of hackage and/or cabal to allow multiple
>> revisions of cabal files per tarball release.  IIUC, the `cabal get`
>> utility takes care of automatically updating the cabal file to the
>> latest revision.
>>
>> I'll have to look more into this later.
>
> Indeed the .cabal files can be revised between releases.  Somehow the
> new revisions get pushed to the all-cabal-files repository [0] with an
> additional "x-revision" key [1], and Hackage picks up the new cabal
> file.  The `cabal` and `stack` utilities substitute the .cabal file from
> the release tarball with the revised .cabal file from Hackage if it is
> newer.
>
> In theory, anything in the .cabal file could be modified, not just
> dependency bounds.  I think guix should use the updated .cabal files for
> better consistency with the rest of the haskell ecosystem, and also for
> less per-package maintenance cost.
>
> How can guix adapt?  Should we somehow incorporate the all-cabal-files
> repository in the haskell build system, adding a post-unpack phase to
> substitute the entire .cabal file?

Packages are build in isolated environments without network.
Therefore it's not possible to access Hackage with a phase of the
build system.  Even if it were possible it would be undesirable
because it would make things non reproducible.

Files not included in the tar can be added as origin inputs to a
package definition (see the testsuite for GHC in the ghc package).
However, they are verified with hashes. Any change to those files will
break the package.

Fede

Re: updating many haskell packages

[Troy Sankey]

Quoting Troy Sankey (2017-02-06 16:00:29)
> Quoting Federico Beffa (2017-02-06 15:34:47)
> > I would consider a discrepancy between a cabal file on Hackage and the
> > actual cabal file included in a tar archive a bug.  It may be helpful
> > to report it to the author.
> 
> I found this issue on the hackage github:
> 
> https://github.com/haskell/hackage-server/issues/503
> 
> It looks like it's a feature of hackage and/or cabal to allow multiple
> revisions of cabal files per tarball release.  IIUC, the `cabal get`
> utility takes care of automatically updating the cabal file to the
> latest revision.
> 
> I'll have to look more into this later.

Indeed the .cabal files can be revised between releases.  Somehow the
new revisions get pushed to the all-cabal-files repository [0] with an
additional "x-revision" key [1], and Hackage picks up the new cabal
file.  The `cabal` and `stack` utilities substitute the .cabal file from
the release tarball with the revised .cabal file from Hackage if it is
newer.

In theory, anything in the .cabal file could be modified, not just
dependency bounds.  I think guix should use the updated .cabal files for
better consistency with the rest of the haskell ecosystem, and also for
less per-package maintenance cost.

How can guix adapt?  Should we somehow incorporate the all-cabal-files
repository in the haskell build system, adding a post-unpack phase to
substitute the entire .cabal file?

Troy

[0] https://github.com/commercialhaskell/all-cabal-files
[1] 
https://github.com/commercialhaskell/all-cabal-files/blob/hackage/old-time/1.1.0.3/old-time.cabal#L3


signature.asc
Description: signature

Re: updating many haskell packages

[Troy Sankey]

Quoting Federico Beffa (2017-02-06 03:13:16)
> On Mon, Feb 6, 2017 at 9:03 AM, Federico Beffa  wrote:
> 
> > (ii) The latest LTS still uses GHC 8.0.1.  I'm not sure if this is
> > because of some real problem (GHC 8.0.2 introduces some
> > incompatibilities) or if it is because changing things takes time.
> 
> Looks like LTS8 is on its way http://lwm.github.io/stackage-8.0.2/

Stackage LTS 8.0 has been released:

https://www.stackage.org/lts-8.0

In the coming days, I'll work to make all our current haskell packages
(and my additions) converge to LTS 8.0.  I may backport the stackage
importer [0] if I need to, but I don't expect that it will be required.

Troy

[0] https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00270.html


signature.asc
Description: signature

Re: updating many haskell packages

[Troy Sankey]

Quoting Federico Beffa (2017-02-06 15:34:47)
> I would consider a discrepancy between a cabal file on Hackage and the
> actual cabal file included in a tar archive a bug.  It may be helpful
> to report it to the author.

I found this issue on the hackage github:

https://github.com/haskell/hackage-server/issues/503

It looks like it's a feature of hackage and/or cabal to allow multiple
revisions of cabal files per tarball release.  IIUC, the `cabal get`
utility takes care of automatically updating the cabal file to the
latest revision.

I'll have to look more into this later.

Troy


signature.asc
Description: signature

Re: updating many haskell packages

[Federico Beffa]

On Mon, Feb 6, 2017 at 4:23 PM, Troy Sankey  wrote:
> Hm, I should have been following a stackage LTS.  Maybe I wouldn't need
> to relax any dependency versions.  I also wonder if I could have avoided
> some discrepancies between hackage and released .cabal files regarding
> dependency versions (there are quite a few [0]).

As far as I know in the past NIX was aggressively removing upper
version constraints, but this seems to have led to problems and they
changed policy:
http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015608.html

Having a set of compatible packages is one of the key Stackage goals
https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package
If the project takes traction (as it seems) this problem should disappear.

I would consider a discrepancy between a cabal file on Hackage and the
actual cabal file included in a tar archive a bug.  It may be helpful
to report it to the author.

Regards,
Fede

[...]

> [0]
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1375
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1404
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1537
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1594
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1944
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1987
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L2018
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L5902
> https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L8793

Re: updating many haskell packages

[Leo Famulari]

On Mon, Feb 06, 2017 at 12:23:23AM -0500, Troy Sankey wrote:
> I wonder how I should send these patches after I'm all done.  git
> send-email?  That seems crazy.

Dozens of patches in their own messages is a little hard to work with as
a reviewer. But, you can put them all in one patch file that is trivial
to apply to my Git tree:

$ git format-patch your-branch..master --stdout > patch-series.patch

And on my end:

$ git am patch-series.patch


signature.asc
Description: PGP signature

Re: updating many haskell packages

[Troy Sankey]

Quoting Federico Beffa (2017-02-06 03:03:34)
> Troy Sankey  writes:
> 
> > I have a WIP branch which contains many haskell package updates and
> > additions, and makes haskell-build-system use the latest ghc (8.0.2).
> >
> > https://github.com/pwnage101/guix/tree/add-gitit
> >
> > It started as a small project to create a Gitit package (hence the name
> > of the branch), but blew up into something larger.  It's hard work, so I
> > just wanted to check in with you all to see if this seems like the right
> > direction.
> >
> > As of this writing, I have over 66 packages updated, 16 added, and
> > various fixes on existing packages to get everything buildable against
> > ghc@8.0.2.  I'm debating whether I should systematically update all the
> > haskell packages while I'm at it, or just make sure everything is
> > buildable under 8.0.2.  There are over 277 haskell packages in all.
> >
> > I wonder how I should send these patches after I'm all done.  git
> > send-email?  That seems crazy.
> 
> I agree, it's a lot of work and guaranteeing package compatibility is
> not straightforward.  To simplify things I would like to suggest to
> exploit the work done by Stackage (www.stackage.org) and follow the
> latest LTS release.

Hm, I should have been following a stackage LTS.  Maybe I wouldn't need
to relax any dependency versions.  I also wonder if I could have avoided
some discrepancies between hackage and released .cabal files regarding
dependency versions (there are quite a few [0]).

> I prepared a 'stackage' importer.  It looks up the list of packages at
> https://www.stackage.org/lts (can select which LTS version), extract the
> version used there and downloads that version of the package from
> hackage (with the hackage importer).
> 
> Two points are open:
> 
> (i) I still need to finish the updater (to work with 'refresh').

TIL guix refresh.  TIL stackage LTS.  I am slow to learn...

> (ii) The latest LTS still uses GHC 8.0.1.  I'm not sure if this is
> because of some real problem (GHC 8.0.2 introduces some
> incompatibilities) or if it is because changing things takes time.
> 
> I will probably be able to share the importer/updater in one week (don't
> have much time to work on it during the week).
> 
> Regards,
> Fede

Awesome :)

Troy

[0]
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1375
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1404
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1537
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1594
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1944
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L1987
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L2018
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L5902
https://github.com/pwnage101/guix/blob/00cc2021d9f3019c8dc69383ff2038eb54d1ba5a/gnu/packages/haskell.scm#L8793


signature.asc
Description: signature

Re: updating many haskell packages

[Federico Beffa]

On Mon, Feb 6, 2017 at 9:03 AM, Federico Beffa  wrote:

> (ii) The latest LTS still uses GHC 8.0.1.  I'm not sure if this is
> because of some real problem (GHC 8.0.2 introduces some
> incompatibilities) or if it is because changing things takes time.

Looks like LTS8 is on its way http://lwm.github.io/stackage-8.0.2/

Re: updating many haskell packages

[Federico Beffa]

Troy Sankey  writes:

> I have a WIP branch which contains many haskell package updates and
> additions, and makes haskell-build-system use the latest ghc (8.0.2).
>
> https://github.com/pwnage101/guix/tree/add-gitit
>
> It started as a small project to create a Gitit package (hence the name
> of the branch), but blew up into something larger.  It's hard work, so I
> just wanted to check in with you all to see if this seems like the right
> direction.
>
> As of this writing, I have over 66 packages updated, 16 added, and
> various fixes on existing packages to get everything buildable against
> ghc@8.0.2.  I'm debating whether I should systematically update all the
> haskell packages while I'm at it, or just make sure everything is
> buildable under 8.0.2.  There are over 277 haskell packages in all.
>
> I wonder how I should send these patches after I'm all done.  git
> send-email?  That seems crazy.

I agree, it's a lot of work and guaranteeing package compatibility is
not straightforward.  To simplify things I would like to suggest to
exploit the work done by Stackage (www.stackage.org) and follow the
latest LTS release.

I prepared a 'stackage' importer.  It looks up the list of packages at
https://www.stackage.org/lts (can select which LTS version), extract the
version used there and downloads that version of the package from
hackage (with the hackage importer).

Two points are open:

(i) I still need to finish the updater (to work with 'refresh').

(ii) The latest LTS still uses GHC 8.0.1.  I'm not sure if this is
because of some real problem (GHC 8.0.2 introduces some
incompatibilities) or if it is because changing things takes time.

I will probably be able to share the importer/updater in one week (don't
have much time to work on it during the week).

Regards,
Fede