Haskell in Nixpkgs/NixOS | 695 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 139 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Oct 2025 | ||
| this is miso so maybe miso is broken, ill try a different commit ig | 19:31:01 | |
| can you expand the error on the browser console? | 19:39:57 | |
| rolling back miso "fixed it" i may revisit this at some point but rn i actually want to write some code 🥲 | 21:35:30 | |
| ive been trying to get this working for the last 2 months | 21:35:37 | |
| 24 Oct 2025 | ||
| 01:23:08 | ||
| 04:50:22 | ||
| 25 Oct 2025 | ||
| 09:30:09 | ||
| 26 Oct 2025 | ||
| I'm trying to build a project that has build-depends on both
If I pin to nixos-25.05 it works, so it must be a recent breakage. | 12:50:29 | |
| Well, "breakage". | 12:55:39 | |
| 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 | |
| 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 | |
| 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 | |
| * 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 | |
| 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 | |
| Best fix is probably to apply the overlay to hls-plugin-api in nixpkgs. | 13:28:01 | |
| https://github.com/NixOS/nixpkgs/pull/455884 | 14:38:45 | |
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:34:08 | |
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 | |
| 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 | |
* 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 | |
| * 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 | |
| * 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 | |
| * 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:40:31 | |
| 27 Oct 2025 | ||
| well it implicitly assumes you need to compile Setup.hs | 13:47:17 | |
| hmm I see, you always potentially need native ghc for that | 14:24:12 | |
| but it makes sense to always wrap cross cabal no? otherwise what is its point | 14:32:08 | |
| * but it makes sense to always wrap cabal from the pkgsCros set no? otherwise what is its point | 14:32:19 | |
| 23:56:39 | ||
| 29 Oct 2025 | ||
| 19:32:52 | ||
| 30 Oct 2025 | ||
| difficult question imo | 06:31:28 | |