| 13 Feb 2026 |
|  hoplopf joined the room. | 10:19:51 |
 chreekat | as a sanity check, if a tool was introduced that created a drv for every source file of every haskell dependency of your haskell package, that would be unreasonable, right? Way too many drvs? | 15:04:19 |
 maralorn | Not necessarily. Probably? Eval times might be horrendous. But I wouldn't bet on that. The question is usually what this drvs do and for many usecases, like e.g. compiling the overhead per drv makes it very slow. | 15:09:47 |
| chreekat | interestin | 15:11:09 |
| chreekat | * interesting | 15:11:12 |
| chreekat | context is that i'm experimenting with using casa as a source for package sources. Right now, the tool fetches tree manifests and blobs from casa and assembles them into a package source tree that can be built in a later step | 15:12:04 |
| chreekat | using IFD it's unusable, but the goal is to try using dynamic derivations / rfc92 | 15:12:38 |
| chreekat | (pre-generation would be another option) | 15:13:27 |
| maralorn | I have optimised our work CI by making on hlint/ormulo check derivation per file. Without caching it is a bit slower but once the store is populated the speedup is significant. | 15:14:01 |
| maralorn | * | 15:14:28 |
 toonn | chreekat: Isn't that what haskell.nix does? | 15:16:18 |
| chreekat | it doesn't use casa as far as I know. | 15:21:33 |
| toonn | No, re drv per Cabal component. Though that's not exactly what you said, I suppose. | 15:22:20 |
| maralorn | Per Cabal component and per source file is a big difference | 15:23:14 |
| chreekat | Yeah, and ironically per-component builds aren't my goal right now. My main goals are to make a tool that lets stack.yaml(.lock) be the source of truth for a nix build, that is also fast. I guess using casa is an orthogonal goal, but it feels right because casa is, or could be, a better solution than the all-cabal-hashes repo | 15:25:07 |
| chreekat | it was sort of the next generation of "better interface to hackage" that fp complete was experimenting with. stack uses it, but besides that it sort of got trapped in amber as fpco moved away from haskell | 15:25:59 |
| chreekat | woo, the ginormous IFD fetch of all sources finally finished, it's compling shit now | 15:37:12 |
 linj | I am also interested in dyn drv. Could you share some learning materials of it? | 16:06:15 |
| chreekat | well, i don't really know of any. I myself am building this experiment in hopes of learning something about it | 16:47:19 |
| chreekat | confession: i am using claude. But I'm minimizing the blast damage by compartmentalizing the steps and checking carefully all the parts I do understand | 16:48:52 |
 alexfmpe | In reply to @b:chreekat.net
as a sanity check, if a tool was introduced that created a drv for every source file of every haskell dependency of your haskell package, that would be unreasonable, right? Way too many drvs? https://github.com/obsidiansystems/sandstone | 17:04:11 |
| linj | tip: there are slides in the slides branch | 17:51:34 |
|  Perigord changed their profile picture. | 19:11:38 |
 Alex | It shouldn't be, but I think this is mostly a question of how efficiently Nix can handle derivations.
I suspect that there is little effort put into making them low overhead, given how little of Nixpkgs creates such small derivations. | 19:41:09 |
| alexfmpe | summon John Ericson | 19:49:32 |
 John Ericson | hi | 20:18:57 |
| John Ericson | see sandstone | 20:19:17 |
| John Ericson | git@github.com:obsidiansystems/sandstone.git | 20:19:36 |
 Sigmanificient | the summoning ritual worked :D | 20:19:37 |
| John Ericson | * https://github.com/obsidiansystems/sandstone | 20:19:52 |
