| 23 Oct 2025 |
 magic_rb | i need to bump nixpkgs anyway due to a broken aeson i think | 18:47:32 |
 alexfmpe | might want to bump to the commit above, at least until the eval error is sorted out | 19:20:10 |
| alexfmpe | ^ | 19:20:15 |
| magic_rb | In reply to @alexfmpe:matrix.org
might want to bump to the commit above, at least until the eval error is sorted out compiling for me, still not working, but neither jsaddle nor js is working so i think im doing something very very wrong | 19:29:39 |
| alexfmpe | what does 'not working' mean | 19:30:01 |
| magic_rb | 
Download clipboard.png | 19:30:33 |
| magic_rb | same error on both js and jsaddle | 19:30:40 |
| magic_rb | 🤔 | 19:30:45 |
| magic_rb | this is miso so maybe miso is broken, ill try a different commit ig | 19:31:01 |
| alexfmpe | can you expand the error on the browser console? | 19:39:57 |
| magic_rb | rolling back miso "fixed it" i may revisit this at some point but rn i actually want to write some code 🥲 | 21:35:30 |
| magic_rb | ive been trying to get this working for the last 2 months | 21:35:37 |
| 24 Oct 2025 |
|  andreabedini changed their display name from andreabedini to Andrea. | 01:23:08 |
| andreabedini changed their display name from Andrea to andreabedini. | 04:50:22 |
| 25 Oct 2025 |
|  Nigel joined the room. | 09:30:09 |
| 26 Oct 2025 |
 ners | I'm trying to build a project that has build-depends on both haskell-language-server and hls-plugin-api.
Getting the following error when trying to build it with Nix:
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: dosh-24.11 (user goal)
[__1] trying: lsp-client-0.4.0.0/installed-9paX9qIvVp6G32qMeolaRR (dependency of dosh)
[__2] next goal: hls-plugin-api (dependency of dosh)
[__2] rejecting: hls-plugin-api-2.11.0.0/installed-4lbla6iVQTHCJxg4ni6oA8 (conflict: lsp-client => lsp==2.7.0.1/installed-5hx47Y1LdOnAB7d5AgUCZ9, hls-plugin-api => lsp==2.7.0.1/installed-G2N8IrC9NSyIKEvHjZgyEW)
[__2] trying: hls-plugin-api-2.11.0.0/installed-IPU6Rknqm9R6YyD99rrbxT
[__3] next goal: haskell-language-server (dependency of dosh)
[__3] rejecting: haskell-language-server-2.11.0.0/installed-AGaYptnU925K1vcaCIwSpk (conflict: hls-plugin-api==2.11.0.0/installed-IPU6Rknqm9R6YyD99rrbxT, haskell-language-server => hls-plugin-api==2.11.0.0/installed-4lbla6iVQTHCJxg4ni6oA8)
[__3] fail (backjumping, conflict set: dosh, haskell-language-server, hls-plugin-api)
If I pin to nixos-25.05 it works, so it must be a recent breakage.
| 12:50:29 |
 maralorn | Well, "breakage". | 12:55:39 |
| maralorn | The problem is that we are fixing hls with an overrideScope in config…-common.nix and that overlay one is not being applied to the exposed hls-plugin-api package. | 12:57:07 |
| maralorn | More generally when somehow beating hls into compiling I generally don’t consider downstream consumers who link against it. I wasn’t aware of their existence. | 12:58:12 |
| ners | It's a thing that should work (the usage is valid) but does not. It even used to work, but has stopped working. That's by definition a breakage. :) | 13:08:45 |
| ners | * It's a thing that should work (the usage is valid) but does not. It even used to work, but has stopped working due to recent changes. That's by definition a breakage. :) | 13:09:09 |
| maralorn | Well if I had considered it breakage I probably wouldn’t have broken it. Sorry, about that, I now know better. We generally have quite a few cases where executable packages are configured in a way that they are not feasible to consume as libraries. | 13:25:56 |
| maralorn | Best fix is probably to apply the overlay to hls-plugin-api in nixpkgs. | 13:28:01 |
| ners | https://github.com/NixOS/nixpkgs/pull/455884 | 14:38:45 |
| alexfmpe | should shellFor have a withCabal boolean or so?
in the native case it can just go in nativeBuildInputs, but since for cross shellFor what we place in PATH isn't 'ghcbut<prefix>-ghc you need this sort of wrapping https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta/-/blob/104d440e93fc05fefd36441e95013eda4b06f611/pkgs/wasm32-wasi-cabal.nix#L62-67 another options is having unprefixedghc, ghc-pkg`, etc point to the prefixed ones | 15:34:08 |
| alexfmpe | the current behavior of pkgsCross.foo.haskellPackages.shellFor is that both native ghc* and <prefix>-ghc* are in PATH, which is pretty odd to me | 15:35:02 |
| alexfmpe | well not odd per-se, I can see the benefit of having both available in a single shell, but certainly unexpected when extrapolating from native shellFor | 15:35:39 |
| alexfmpe | * should shellFor have a withCabal boolean or so?
in the native case it can just go in nativeBuildInputs, but since for cross shellFor what we place in PATH isn't 'ghc but<prefix>-ghc you need this sort of wrapping https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta/-/blob/104d440e93fc05fefd36441e95013eda4b06f611/pkgs/wasm32-wasi-cabal.nix#L62-67 another options is having unprefixedghc, ghc-pkg`, etc point to the prefixed ones | 15:36:00 |
| alexfmpe | * should shellFor have a
withCabal boolean or so?
in the native case it can just go in nativeBuildInputs, but since for cross shellFor what we place in PATH isn't `ghc` but `<prefix>-ghc` you need this sort of wrapping https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta/-/blob/104d440e93fc05fefd36441e95013eda4b06f611/pkgs/wasm32-wasi-cabal.nix#L62-67 another options is having unprefixed `ghc`, `ghc-pkg`, etc point to the prefixed ones | 15:37:11 |
| alexfmpe | * should shellFor have a
withCabal boolean or so?
in the native case it can just go in nativeBuildInputs, but since for cross shellFor what we place in PATH isn't `ghc` but `<prefix>-ghc` you need this sort of wrapping https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta/-/blob/104d440e93fc05fefd36441e95013eda4b06f611/pkgs/wasm32-wasi-cabal.nix#L62-67
another option is having unprefixed `ghc`, `ghc-pkg`, etc point to the prefixed ones | 15:37:42 |
