!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

720 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/144 Servers

Load older messages


SenderMessageTime
30 Mar 2026
@janus.troelsen:matrix.orgJanus* It was a mess with the vibe-coded removal and re-addition of stuff, but it's good that an attempt is being made to take over the package. Jappie has good intentions and seems open to constructive feedback.16:29:29
@mangoiv.:matrix.orgMangoIV

Jappie has good intentions and seems open to constructive feedback.

He definitely does, but that doesn't make me less caucious of vibe coding

16:30:38
@andreaspk:matrix.organdreaspk joined the room.18:38:03
5 Apr 2026
@alexfmpe:matrix.orgalexfmpe

there's a couple packages calling cabal executables in their test suites that I tried to fix with addTestToolDepend self.cabal-install that then fail with

Error: [Cabal-8123]
Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
00:30:02
@alexfmpe:matrix.orgalexfmpe I dunno where that GHC_PACKAGE_PATH is coming from. is this something worth addressing on nixpkgs? if not, could I somehow fix upstream? 00:31:05
6 Apr 2026
@alex:tunstall.xyzAlex

,("Use interpreter","NO")
,("cross compiling","NO")
,("Build platform","riscv64-unknown-linux")
,("Host platform","riscv64-unknown-linux")
,("Target platform","riscv64-unknown-linux")
,("Have interpreter","NO")

Why is my native RISC-V GHC 9.8.4 build missing the TH interpreter and GHCi support?
I've never seen this happen for a native build before, and I can't find anything that explains this in Nixpkgs or Hadrian's source code.

I have an old native 9.6.6 build lying around and it has ("Have interpreter","YES") as expected.
Both were built using Nixpkgs' default settings with a cross-compiled GHC 9.4.8.

08:47:00
@alex:tunstall.xyzAlex Oh, nevermind, I found the issue.
I removed this patch while upgrading Nixpkgs because the default GHC (9.10) has the commit, but then later found that to get there I needed to first build 9.6 or 9.8, which don't have the commit.
08:50:58
@alexfmpe:matrix.orgalexfmpeNix on macos room (unlinkable right now) is asking what is the purpose of ghc-standalone-archive11:25:47
@sternenseemann:systemli.orgsterni

alexfmpe: see

  • https://github.com/haskell/cabal/issues/2358
  • https://github.com/NixOS/nixpkgs/pull/312859
  • https://github.com/haskell/cabal/issues/10090

for some context

11:27:52
@sternenseemann:systemli.orgsterniask Shea Levy, I guess. I assume it is intended for building a static archive of Haskell libs you can link into iOS applications. I have never seen anybody talking about it or using it, so I'm fine with removing it personally.11:31:03
@alexfmpe:matrix.orgalexfmpe
In reply to @sternenseemann:systemli.org

alexfmpe: see

  • https://github.com/haskell/cabal/issues/2358
  • https://github.com/NixOS/nixpkgs/pull/312859
  • https://github.com/haskell/cabal/issues/10090

for some context

Ah got it. Mind if I cook up a couple utils for these unfortunately common test suite tweaks? HOME/tmpDir, ghc_package_path
11:32:34
@sternenseemann:systemli.orgsterniyes, sure may be worth refactoring11:32:56
@alexfmpe:matrix.orgalexfmpeThe pre check exports, that is11:33:02
@sternenseemann:systemli.orgsternithe thing is that there can't really be a generic solution for everything because there are a lot of mutually incompatible approaches to solving this at the moment.11:34:22
@alexfmpe:matrix.orgalexfmpeSure, but we can have a ready made sane default 11:34:50
@sternenseemann:systemli.orgsterniw.r.t. your specific question if you look at the GHC_PACKAGE_PATH stuff, we have a way of preventing our wrapper from setting that if you need cabal. But i expect it'll break in a different way then.11:35:18
@sternenseemann:systemli.orgsterniif someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages11:36:17
@alexfmpe:matrix.orgalexfmpeI suspect stack also doesn't set it. First saw this when packaging haskell-debugger and IIRC stack test also got tripped up, only cabal test was green11:36:57
@sternenseemann:systemli.orgsternicabal sets GHC_ENVIRONMENT which is annoying to replicate manually unfortunately.11:37:26
@sternenseemann:systemli.orgsterni but it also doesn't do everything for some use cases you need to run cabal v2-exec -- cabal v2-test (i think path being set) 11:37:52
@alexfmpe:matrix.orgalexfmpe
In reply to @sternenseemann:systemli.org
if someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages
That's huh, big. Right now I'm only trying to fix a couple packages without excessive copy pasting
11:38:01
@sternenseemann:systemli.orgsternidon't worry about it, I don't think it solves much we are facing right now. cabal-install also has plenty of problems.11:39:18
@sternenseemann:systemli.orgsternii just feel like it may be wise long term since every solution for rough spots in cabal nowadays get designed around cabal-install v2-commands and they are often implemented poorly in Setup.hs to the degree that they are outright broken e.g. https://github.com/haskell/cabal/issues/1159811:40:37
@sternenseemann:systemli.orgsterni(the build-tool-depends thing btw si another example for a stupid hack packages use to get the executable into PATH for the test suite)11:41:00
@alexfmpe:matrix.orgalexfmpeI do think it's worth looking into at some point down the line, just have a bunch of other cabal2nix/haskellPackages stuff on my queue already11:57:27
9 Apr 2026
@eliasp:kde.orgeliasp joined the room.14:13:34
@eliasp:kde.orgeliasp

Hi
I have very little knowledge when it comes to the general Haskell ecosystem/build process etc - I'm struggling with applying a custom patch via haskell.lib.compose.appendPatch to a package (hledger).
It fails applying the patch, complaining it can't find the file targeted in the patch…

       > applying patch /nix/store/s3f1dgvk0ddzp87sg9j2npb7j7avdanw-imp-add-continue-rule-for-CSV-import.patch
       > can't find file to patch at input line 3
       > Perhaps you used the wrong -p or --strip option?
       > The text leading up to this was:
       > --------------------------
       > |--- a/hledger-lib/Hledger/Read/RulesReader.hs
       > |+++ b/hledger-lib/Hledger/Read/RulesReader.hs
       > --------------------------
       > File to patch:
       > Skip this patch? [y]
       > Skipping patch.

Do I need to do anything special to apply patches to Haskell packages? Couldn't find anything relevant to my problem in the docs.

14:18:02
@eliasp:kde.orgeliasp Oh, nvm - just realized I'm being stupid and should apply the patch to hledger-lib instead of hledger 🤦 14:19:14
@sternenseemann:systemli.orgsterni you also need to use the relative argument of fetchpatch so the paths are correct 15:28:12
10 Apr 2026
@epimonic:matrix.org@epimonic:matrix.org left the room.11:46:02

Show newer messages


Back to Room ListRoom Version: 6