| 11 May 2025 |
 alexfmpe | It basically grabs the deps of the packages you ask to dev on and shoves them in the shell, alongside local hoogle setup if you asked for it | 21:45:42 |
 hellwolf | I wonder if I should just brute force foldMap all propagated-build-inputs | 21:46:17 |
| hellwolf | * I wonder if I should just brute force foldMap all propagated-build-inputs into the generated cabal.project | 21:46:29 |
| alexfmpe | Why do you need a generated cabal.project? | 21:46:47 |
| hellwolf | I can rebuild this wheel, but happy to learn also how to use the existing wheel. | 21:46:51 |
| alexfmpe | I usually just have
packages: *
enable-multi-repl: true | 21:47:17 |
| alexfmpe | * I usually just have
packages: *
multi-repl: True | 21:47:52 |
| 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 small stub project in build folder that use those packages from nix shell.
| 21:49:40 |
| 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 build folder that use those packages from nix shell.
| 21:49:55 |
| 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 from nix shell + your/module
| 21:50:51 |
| 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 |
