| 26 Oct 2025 |
 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 | 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 | difficult question imo | 06:31:28 |
| sterni | 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 |
| alexfmpe | $ grep "callPackage" hackage-packages.nix | wc -l
18654
$ grep "broken = true" hackage-packages.nix | wc -l
7267
a few others won't eval because of platform but that still looks like around 10k that will at least attempt to build
| 23:12:01 |
| 31 Oct 2025 |
 Alex | In reply to @alexfmpe:matrix.org
another option is building whatever deps your planned project has, plus a few dependency heavy hitters It's much lighter if you only fetch all transitively required sources.
Though naturally, that means you need to build whatever you want to use. | 01:56:46 |
| 2 Nov 2025 |
| ➡️@amadaluzia:unredacted.org changed their display name from amadaluzia to ➡️@amadaluzia:unredacted.org. | 22:49:04 |
