| 11 May 2025 |
 hellwolf | * Good question...
Currently I try to wrap the developer experience in my own way:
- nix shell github:to/myproject
- mytool to/your/module
a. this will create a temporary tiny stub cabal project in the local build folder that uses:
those packages obtained from nix shell + your/module
| 21:51:05 |
 alexfmpe | Hmm cabal will just download whatever deps are not provided by callCabal2nix I've had that happen accidentally tons of times when editing .cabal without re entering the shell | 21:52:26 |
| hellwolf | I see. I think you can control that. | 21:52:51 |
| alexfmpe | So IIUC, you already have the layered workfloe? | 21:52:55 |
| alexfmpe | Yeah I disable it nowadays | 21:53:04 |
| alexfmpe | But it sounds like what you wanted? | 21:53:11 |
| hellwolf | yea, it works, but now I want to integrate nix | 21:53:16 |
| hellwolf |
But it sounds like what you wanted?
perhaps yes, because "your/own/module" will more than likely want to have your own dependencies.
| 21:53:40 |
| alexfmpe | I mean, if you're not calling cabal2nix or so on it, then the build tool will grab whatever is missing in the non nix way | 21:54:17 |
| hellwolf | right, let me think a little. not sure how to incorporate nix nicely... | 21:55:20 |
| hellwolf | It seems that fundamentally I have some wrong expectation.
I was hoping to deliver a developer experience such that they don't have to rebuild the packages, which may take few minutes, the first time they use my tool. | 22:31:09 |
 winston | assuming you're able to use a binary cache, you can potentially limit to just having to build once through nixConfig.extra-substituters etc | 22:34:17 |
| hellwolf | that's the start, yes. But then I need to be able to use those built packages again in a cabal project; because I don't intend to push users to build their project with cabal2nix. | 22:35:14 |
| hellwolf | hmm, but maybe I can... | 22:37:17 |
| hellwolf | In a new derivation, I copy bunch of package.conf.d/*.conf to a new folder, and use ghc-pkg --package-db that/new/folder recache | 22:41:37 |
| 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. | 22:41:52 |
| 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 |
