| 11 May 2025 |
 hellwolf | * In a new derivation, I copy a bunch of package.conf.d/*.conf to a new folder, and use ghc-pkg --package-db that/new/folder recache.
That should do it, for my use case. I tried locally, it seems working. | 22:42:14 |
| 12 May 2025 |
 woobilicious | hellwolf: that seems kinda hacky, and might not be very portable (enabling debugging / profiling will trigger another recompile anyway too), is there a reason why you don't want others compling the code on the first run? seems like it would cause more headaches than the 2min first run compile time. | 01:20:13 |
| hellwolf | Indeed. I might give up this for now. It's not 2 minutes though, for a fresh starter, it's about compiling all the dependencies included.
And i just realized that nix is an all or nothing solution: if i want the user to take advantage of the cache, they'd use nix to build and manage dependencies too... | 06:25:10 |
| hellwolf | * Indeed. I might give up this for now. It's not 2 minutes though, for a fresh starter, it's about compiling all the dependencies included.
And i just realized that nix is an all or nothing solution: if i want the user to take advantage of the cache, they'd use nix to build and manage dependencies too...
| 06:25:29 |
| hellwolf | can nixpkgs haskellPackages output anything similar to https://ghc.gitlab.haskell.org/head.hackage/ ? | 06:35:49 |
| hellwolf | That'd be a use case for me: since I tested the entire suite with a specific version of nixpkgs, I should at least let users be able to pin to that in cabal in a way similar to what head.hackage does. | 06:45:10 |
 Daniel Firth | hellwolf: head.hackage is an entire cabal index, it doesn't pin anything, that's done by cabal freeze files (sort of) | 09:13:46 |
| hellwolf | I understand. I guess my question is can we freeze haskellPackages, including the one that I customize locally? | 09:17:21 |
| hellwolf | * I understand. I guess my question is can we freeze haskellPackages for a cabal project to consume, including the one that I customize locally? | 09:17:36 |
| Daniel Firth | Turning a haskell package set into a cabal freeze file sounds possible in theory I guess | 09:24:37 |
| Daniel Firth | (I don't know the cabal freeze format at all actually) | 09:24:56 |
| hellwolf | it seems not hard., and I think it's a very good usecase for distributing "known working" package set | 10:14:08 |
| hellwolf | I am working on a DSL kit, and I don't want to deal with downstream's complain that their randomly tracked cabal package set is broken. | 10:14:43 |
| hellwolf | I want to have a control to eliminate such a support need. Of course, it has its tradeoffs. But I am quite happy with the general up-to-date-ness of nixpkgs haskellPackages | 10:15:25 |
| hellwolf | If you look at head.package, or downstream needs to do is this snippets:
repository head.hackage.ghc.haskell.org
url: https://ghc.gitlab.haskell.org/head.hackage/
secure: True
key-threshold: 3
root-keys:
26021a13b401500c8eb2761ca95c61f2d625bfef951b939a8124ed12ecf07329
7541f32a4ccca4f97aea3b22f5e593ba2c0267546016b992dfadcd2fe944e55d
f76d08be13e9a61a377a85e2fb63f4c5435d40f8feb3e12eb05905edb8cdea89
we could have a https://ghc.gitlab.haskell.org/head.haskellPackages/
| 10:16:34 |
| hellwolf | * If you look at head.package, or downstream needs to do is this snippets:
repository head.hackage.ghc.haskell.org
url: https://ghc.gitlab.haskell.org/head.hackage/
secure: True
key-threshold: 3
root-keys:
26021a13b401500c8eb2761ca95c61f2d625bfef951b939a8124ed12ecf07329
7541f32a4ccca4f97aea3b22f5e593ba2c0267546016b992dfadcd2fe944e55d
f76d08be13e9a61a377a85e2fb63f4c5435d40f8feb3e12eb05905edb8cdea89
we could have a https://ghc.gitlab.haskell.org/head.haskellPackages/ e.g.
| 10:16:36 |
|  Alyssa Ross left the room. | 10:33:13 |
 Teo (he/him) | head.hackage is a few things: a set of patches, a hackage overlay generated from those patches, scripts to test GHC against the patches and some other packages. I think we often overemphasize the hackage overlay, since that's what downstream users consume. But we do fix package versions through the patches we have and the other packages we specify | 10:47:48 |
| Teo (he/him) | And that's what ends up in the freeze file we output | 10:49:39 |
| Teo (he/him) | You might be interested in https://github.com/input-output-hk/foliage, head.hackage is soon switching over to using that to generate the Hackage overlay | 10:50:38 |
| Daniel Firth | hellwolf: You might also be interested in looking at https://horizon-haskell.net although I'm not sure it addresses your problem specifically. | 11:14:14 |
 sterni (he/him) | alexfmpe: https://hydra.nixos.org/build/296940162/nixlog/2 | 12:19:35 |
 alexfmpe | https://github.com/NixOS/nixpkgs/pull/406446 | 13:10:59 |
 thirdofmay18081814goya | anyone use hnix before? | 20:23:17 |
| thirdofmay18081814goya | trying to figure what exactly derivations are | 20:23:31 |
| thirdofmay18081814goya | in order to have a value for which lib.isDerivation returns true, do we need some effectful build procedure to happen? | 20:24:03 |
| thirdofmay18081814goya | hm I would think so given that the interpreter returns a path when you pass a variable that is a derivation to the nix interpreter | 20:25:34 |
| thirdofmay18081814goya | then, constructing a derivation is an effectful, monadic value and it is distinct from the monadic value consisting of running the build procedure specified by the derivation, correct? | 20:27:18 |
 maralorn | I have never used hnix but what you are describing seems very consistent to how nix works. | 21:10:31 |
| maralorn | During the evaluation of a nix expression creating a derivation is also an effectful operation, because it writes the derivation to the nix store. It is in the end a primitive builtin function which creates the derivation and returns an object describing it (e.g. containing it's hashes) which then can be used in further calculations in the nix language. | 21:15:09 |
