| 11 May 2025 |
hellwolf | how do I apply to all dependencies automatically? | 21:04:19 |
hellwolf | I guess doing a map over "pkgs.haskell.packages.${ghcId}" setting "donCheck = true" would be an overkill? | 21:21:41 |
WeetHet | @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? | 21:22:30 |
WeetHet | In reply to @hellwolf:matrix.org I guess doing a map over "pkgs.haskell.packages.${ghcId}" setting "donCheck = true" would be an overkill? mkDerivation = args: hprev.mkDerivation ({ doCheck = false; } // args | 21:26:03 |
WeetHet | This is what I've done, I don't like it but it works | 21:26:26 |
hellwolf | yikes :) | 21:29:48 |
hellwolf | but I realized it was largely my own fault of tracking ghc 9.12.2 already.. only package is broken without a cache is crypton, I will just apply a hack for that package alone. | 21:30:41 |
maralorn | 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? Well, it is generally possible to package haskell packages in by-name. But it is unclear to me what that's supposed to solve. | 21:34:50 |
alexfmpe | In reply to @hellwolf:matrix.org but I realized it was largely my own fault of tracking ghc 9.12.2 already.. only package is broken without a cache is crypton, I will just apply a hack for that package alone. Welcome to the early adopter life | 21:39:26 |
hellwolf | :p | 21:39:56 |
alexfmpe | Here's another fun one | 21:40:00 |
alexfmpe | https://gitlab.haskell.org/ghc/ghc/-/issues/25937 | 21:40:03 |
alexfmpe | I'd be careful about using crypton in prod if test suite doesn't pass | 21:40:41 |
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 |