| 5 Nov 2024 |
 lxsameer | but that's the problem, indirect dependencies will use lib B for test-suit that is in conflict with what we override. | 14:13:18 |
| lxsameer | I can produce an example | 14:13:51 |
|  @grossmap:in.tum.de left the room. | 14:14:59 |
 maralorn | I wouldn’t be surprised if I am overlooking something.
But when an indirect dependency D uses lib B in their test suite then either B does not get overriden, then D should build just fine including the test suite or we are actually changing B, but then we can propagate the test disabling from D to B and B should still build fine. | 14:20:19 |
| lxsameer | I think I need to understand the order that nix evaluate packages first. | 15:31:16 |
 sterni (he/him) | lxsameer: Using mkDerivation = args: super.mkDerivation ({ doCheck = false; } // args); means that any explicit override would still be respected | 16:12:23 |
| sterni (he/him) | this works because the generated expressions never set doCheck explicitly, you can of course get into trouble if any configuration-*.nix sets it, but this seldomly happens in practice | 16:13:22 |
| sterni (he/him) | maralorn: seems a bit overcomplicated :) | 16:14:27 |
| lxsameer | I was thinking about this and I think we can make a compromise. So when a user uses this tool that I'm writing, all the packages that will be used are directly or indirectly are the dependencies of their cabal project. What we can do as a middle ground, is to disable tests and profiling only for direct dependencies and make it optional for the user to disable them with the mkDerivation trick for all of em. | 17:02:25 |
| lxsameer | or we can make it optional to disable tests and profiles by default and make user aware of the problems and the trade off | 17:02:59 |
| lxsameer | This way, someone like me who isn't concerned about building everything again can disable the tests completely for my dependencies. | 17:03:57 |
| lxsameer | maralorn: sterni and people who want to utilize the cache can manually disable the tests on problematic packages | 17:05:35 |
| lxsameer | what do you think about this? | 17:05:51 |
| sterni (he/him) | I think that is a futile exercise. In reality, close to all packages (indirectly) depend on a small set of packages. You are most likely going to differ in some minor way (e.g. a minor version, an additional revision) from upstream nixpkgs which is going to invalidate the entire cache | 17:08:20 |
| sterni (he/him) | you can only reuse cache if you exactly match upstream nixpkgs in almost all versions | 17:09:07 |
| sterni (he/him) | it's also not enough if nixpkgs had the same combinations of packages at some point since changes to compilers, libs etc. independent of Haskell may also invalidate the cache | 17:09:39 |
| sterni (he/him) | in short, if you are able to get cache reuse, it'd probably be easier to just use callCabal2nix without anything else because you are incredibly close to nixpkgs already | 17:10:26 |
| sterni (he/him) | but the whole use case for such a tool would be when you're not close to nixpkgs at all | 17:10:40 |
| sterni (he/him) | besides that, I think it's also probably not ideal to consider this for the first version. first get the thing to work and then you can think about such stuff I'd say | 17:11:27 |
| lxsameer | That makes sense. | 17:13:17 |
| 6 Nov 2024 |
| maralorn | In reply to @sternenseemann:systemli.org
I think that is a futile exercise. In reality, close to all packages (indirectly) depend on a small set of packages. You are most likely going to differ in some minor way (e.g. a minor version, an additional revision) from upstream nixpkgs which is going to invalidate the entire cache That's not my experience. I very frequently do cabal builds where I only need to build a few libs and reuse the global package DB for the rest. Cabal is good at prefering installed packages. | 02:12:42 |
| maralorn | In reply to @sternenseemann:systemli.org
besides that, I think it's also probably not ideal to consider this for the first version. first get the thing to work and then you can think about such stuff I'd say That being said I agree that my suggestion is not a low hanging fruit. | 02:14:16 |
 Manuel Bärenz | I want to update my packages to 9.10 so I can keep them to stackage. I imagine that this will simplify keeping them unbroken in nixpkgs. But when I work on my packages, I'm having trouble. I'll do something like nix develop with a suitable shellFor on GHC 9.10, but this usually doesn't work because a lot of packages on nixpkgs don't yet build with GHC 9.10. So I need to override them manually, which takes a lot of time. (Eventually when the main GHC version on nixpkgs is bumped, I can remove all these overrides again, so this is all temporary noise.) Also, often nix develop thinks it needs to rebuild Cabal, which I almost surely don't want to. | 10:05:13 |
| Manuel Bärenz | It's a bit of a hen-and-egg problem ecosystem-wise. How do other people deal with this? Or am I doing something fundamentally wrong maybe and noone else runs into such troubles? | 10:05:58 |
 chreekat | @manuelbaerenz:matrix.org: I would just give up on the Nix caching and rely on cabal directly. No Nix indirection. Break the egg | 10:09:01 |
| maralorn | In reply to @b:chreekat.net
@manuelbaerenz:matrix.org: I would just give up on the Nix caching and rely on cabal directly. No Nix indirection. Break the egg This is the way. | 10:27:27 |
| maralorn | In reply to @manuelbaerenz:matrix.org
It's a bit of a hen-and-egg problem ecosystem-wise. How do other people deal with this? Or am I doing something fundamentally wrong maybe and noone else runs into such troubles? imo there are two kinds of people, those who test newer versions without nix and those who make us trouble.^^ Interestingly some Nix users are in the second category because of exactly the problem you describe. | 10:29:23 |
| maralorn | imo nix is good for deployment (especially on nixos) and to setup dev envs. It is currently not fit to replace cabal for all dev purposes. | 10:30:26 |
| Manuel Bärenz | Ok, I'm fine with doing nix-shell -p "haskell.packages.ghc910.ghcWithPackages (p: []), or maybe some minimal dependencies that are in the cache, and then cabal build. But I can't setup a dev env. | 10:49:42 |
| Manuel Bärenz | Maybe I'm being to perfectionist here. I basically have a generic devShell section in my flake.nix that is parametrised over the haskell package set. It works for all the older GHCs, but not on GHC 9.10. So adapting your advice would mean to remove that devShell for GHC 9.10 and have a "raw" devShell that has no Haskell package dependencies, but only GHC and whatever tooling is already in the cache? | 10:55:24 |
