| 26 Oct 2025 |
 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 |
| 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:40:31 |
| 27 Oct 2025 |
 sterni (he/him) | well it implicitly assumes you need to compile Setup.hs | 13:47:17 |
| alexfmpe | hmm I see, you always potentially need native ghc for that | 14:24:12 |
| alexfmpe | but it makes sense to always wrap cross cabal no? otherwise what is its point | 14:32:08 |
| alexfmpe | * but it makes sense to always wrap cabal from the pkgsCros set no? otherwise what is its point | 14:32:19 |
|  ➡️@amadaluzia:unredacted.org joined the room. | 23:56:39 |
| 29 Oct 2025 |
|  NickSeagull joined the room. | 19:32:52 |
| 30 Oct 2025 |
| sterni (he/him) | difficult question imo | 06:31:28 |
| sterni (he/him) | it would be nice to have the option, but it’s not clear to me how it should work | 06:31:48 |
| alexfmpe | reminds me of https://github.com/NixOS/nixpkgs/issues/237741 | 12:10:46 |
 shapr | possibly off-topic, but I'm going on a week long vacation and I want to have all of haskellPackages downloaded onto my NixOS system, is there a way to do that? | 22:04:23 |
 magic_rb | nix-fast-build nixpkgs#legacyPackages.x86_64-linux.haskellPackages | 22:40:33 |
| magic_rb | I think | 22:40:37 |
| alexfmpe | that fails eval from hitting all the broken packages no? | 23:06:40 |
| magic_rb | It should keep going | 23:06:53 |
| magic_rb | Or there may be a flag | 23:06:57 |
| magic_rb | It internally calls nix-eval-jobs which can definitely just keep going. We use it inside of buildbot-nix | 23:07:36 |
| alexfmpe | wait do you really want ALL of it? that's thousands of packages, all taking up disk space | 23:08:37 |
| alexfmpe | another option is building whatever deps your planned project has, plus a few dependency heavy hitters | 23:09:35 |
| alexfmpe | HLS alone has like 250 | 23:09:39 |
