* Haskel LTS 12.8. @ 2018-08-29 16:39 Timothy Sample 2018-08-29 18:51 ` Ricardo Wurmus 0 siblings, 1 reply; 4+ messages in thread From: Timothy Sample @ 2018-08-29 16:39 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel Hi Ricardo (and Guix), 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. 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. If you have any issues with this approach now would be a good time to bring them up! :) -- Tim ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Haskel LTS 12.8. 2018-08-29 16:39 Haskel LTS 12.8 Timothy Sample @ 2018-08-29 18:51 ` Ricardo Wurmus 2018-08-29 21:53 ` Timothy Sample 0 siblings, 1 reply; 4+ messages in thread From: Ricardo Wurmus @ 2018-08-29 18:51 UTC (permalink / raw) To: Timothy Sample; +Cc: guix-devel 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.) > 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. -- Ricardo ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Haskel LTS 12.8. 2018-08-29 18:51 ` Ricardo Wurmus @ 2018-08-29 21:53 ` Timothy Sample 2018-08-30 19:46 ` Timothy Sample 0 siblings, 1 reply; 4+ messages in thread From: Timothy Sample @ 2018-08-29 21:53 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel Hello, Ricardo Wurmus <rekado@elephly.net> 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. >> 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Haskel LTS 12.8. 2018-08-29 21:53 ` Timothy Sample @ 2018-08-30 19:46 ` Timothy Sample 0 siblings, 0 replies; 4+ messages in thread From: Timothy Sample @ 2018-08-30 19:46 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel Hi Again, Timothy Sample <samplet@ngyro.com> writes: > Hello, > > Ricardo Wurmus <rekado@elephly.net> 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-08-30 19:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-29 16:39 Haskel LTS 12.8 Timothy Sample 2018-08-29 18:51 ` Ricardo Wurmus 2018-08-29 21:53 ` Timothy Sample 2018-08-30 19:46 ` Timothy Sample
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.