| 11 May 2025 |
 alexfmpe | Well maybe it doesn't matter if it's for come cypher you don't use it? | 21:41:06 |
| alexfmpe | * Well maybe it doesn't matter if it's for some cypher you don't use it? | 21:41:17 |
 hellwolf | Yea, I don't heavily use it. | 21:41:18 |
| hellwolf | only a few small routine, non crytical | 21:41:25 |
| hellwolf | * only a few small routine, non critical. | 21:41:29 |
| hellwolf | Now that I got packages built, should I expect to have one single package.db that tracks all the dependencies, or I need to get those list myself...
I am asking because I handcraft such a cabal.project automatically for the projects using the my tool:
package-dbs: clear, global, ${cabal_package_db}, ${yolc_package_db}
| 21:42:25 |
| alexfmpe | In reply to @weethet:catgirl.cloud
@maralorn:maralorn.de re: packaging latest versions, would defining a package in by-name also work or will there be a conflict between the two? How is that different than just using the latest includes version? we bundle hackage latest alongside LTS version when they differ | 21:42:30 |
| alexfmpe | self.foo = super.foo_1_2_3 | 21:43:00 |
| alexfmpe | The 9.10 and 9.12 override files do a lot of this | 21:43:15 |
| hellwolf | for individual package, I see:
- package.conf.d
- nix-support
these kinds of files.
sorry, for cross talking now.
| 21:43:58 |
| alexfmpe | In reply to @hellwolf:matrix.org
Now that I got packages built, should I expect to have one single package.db that tracks all the dependencies, or I need to get those list myself...
I am asking because I handcraft such a cabal.project automatically for the projects using the my tool:
package-dbs: clear, global, ${cabal_package_db}, ${yolc_package_db}
I dunno about that file, but inside shellFor, my ghc-pkg list works as expected | 21:44:15 |
| alexfmpe | Oh cabal.project? | 21:44:31 |
| hellwolf | similar mechenism, I need to look into how shellFor is implemented. | 21:45:02 |
| hellwolf | * similar mechanism. I think I need to look into how shellFor is implemented. | 21:45:13 |
| 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 |
