| 25 Sep 2025 |
 bglgwyng | * If a package is not affected by foo-package.override { random = ... }, which means random is not overridden but remains as the one in haskellPackages, what are some things I can try to investigate further? | 09:00:44 |
 maralorn | I can’t think of anything straightforward. Best ideas is a) there is a second override which negates your first override b) you are mistakingly not actually passing a different random. I can think of wilder theories, but they will be even more likely to be wrong. | 09:30:59 |
| bglgwyng | I tried overriding it at the last place like,
{ packages.hip = config.cabal-projects.default.packages.hip.override { random = config.cabal-projects.default.packages.random; }; }
but still same
| 09:32:13 |
 sterni | bglgwyng: Haskell dependencies need to be propagated, so any given package sees its transitive Haskell dependency closure. random is pretty common, so probably somewhere the non overridden random is visible. Cabal is free to pick any version within bounds. | 10:58:17 |
| sterni | hip doesn't have bounds on random at all, so maybe it picks another version? You can force it a specific version via the --constraint configure flag, but you'll likely run into trouble with this since Haskell isn't designed for multiple versions of the same package being linked into the same end product. | 10:59:55 |
| sterni | The only robust way of overridding a package that occurs multiple times in the dependency closure of a give package is to use overrideScope and recompiling (a large portion of) the dependency closure. | 11:00:42 |
| sterni | or do you mean something else by "not affected by"? | 11:01:07 |
| bglgwyng | No. your understanding is correct | 11:02:43 |
| bglgwyng | I should check for it now, but I'm so sure that I override every package depends on random with the same version of random | 11:03:14 |
| bglgwyng | So transitively depended random should be the same | 11:03:37 |
| bglgwyng | Even if I did so, does the problem you describe can occur for some reasons? | 11:04:05 |
| bglgwyng | Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package hip (hip-1.5.6.0) requires random-1.2.1.3-37JdwX1MChN5J4YOL6CRA5
package temporary (temporary-1.3-D9AnthCRrFGJbyvBi0CXlS) requires random-1.2.1.3-wWDAMRL8k9YVWnjsPAPC
package linear (linear-1.23.2-3JDfk2hoPGIIa6oUPVB0FE) requires random-1.2.1.3-wWDAMRL8k9YVWnjsPAPC
package QuickCheck (QuickCheck-2.15.0.1-LDCjebZP9NmJJekAZt2vVq) requires random-1.2.1.3-wWDAMRL8k9YVWnjsPAPC
package random (random-1.2.1.3-37JdwX1MChN5J4YOL6CRA5) requires splitmix-0.1.1-JnFxtR8Qwyw2CyoVPkB8hj
package random (random-1.2.1.3-wWDAMRL8k9YVWnjsPAPC) requires splitmix-0.1.3.1-1AXCbj2oPlfCvSRlfGtm8v
package QuickCheck (QuickCheck-2.15.0.1-LDCjebZP9NmJJekAZt2vVq) requires splitmix-0.1.3.1-1AXCbj2oPlfCvSRlfGtm8v
I got this message, and I override random for every package depending on it
| 11:11:43 |
| bglgwyng | Hmm... I'm reading generic-builder.nix and found ${setupCommand} register --gen-pkg-config=$packageConfFile this code | 11:27:10 |
| bglgwyng | Maybe generic-builder doesn't explicitly passing overrided packages, but just putting them in package-db and letting cabal resolve it? | 11:27:36 |
 toonn | The different hashes do seem to indicate that they're different instances of the package, no? | 11:37:01 |
| bglgwyng | Yes they are different | 11:40:57 |
| bglgwyng | I wonder if generic-builder can distinguish them during build | 11:41:25 |
| maralorn | bglgwyng: I am not 100% sure but from my experience: Cabal will prefer the overriden one over the default except in the following situations:
- Some dependency is already using the default and none the override. (i.e. the only way to get a coherent build plan.)
- There is a constraint which prevents usage of the overriden one.
But this is really murky and I could be wrong.
| 11:54:31 |
| sterni | bglgwyng: the issue appears to be that you are building random with different versions of splitmix in these cases | 11:58:24 |
| sterni | so you need to make sure that the splitmix version is consistent as well | 11:58:33 |
| bglgwyng | ah, I'll figure out why 2 random packages are built, but in my case, build with duplicated packages should work well since I explicitly override them by plan.json result | 11:59:48 |
| bglgwyng | I suppose that we don't have force generic-builder to use a specific package with id | 12:00:43 |
| bglgwyng | * I suppose that we don't have a way to force generic-builder to use a specific package with id | 12:01:26 |
| maralorn | I think Setup.hs has a mode to do that. But we currently don’t use it in the generic-builder and it might be non trivial. | 12:02:16 |
| bglgwyng | Thanks! but, wht does 'non trivial' mean here? | 12:03:04 |
| maralorn | It means, that it could be that a) if you do this you need to specify the hashes of all dependencies (and I think in that mode you disable bound checking completely) and b) it might be hard to figure out the correct hashes to inject there. Basically we would be reimplementing logic which we currently rely on from Setup.hs. | 12:12:26 |
| maralorn | Does not sound insurmantable. | 12:12:47 |
| maralorn | It might even be feasible do improve the generic-builder to enforce the usage of passed in overrides more reliably in general. That could be cool. | 12:13:28 |
| maralorn | * Does not sound insurmountable. | 12:13:43 |
| sterni | https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-dependency | 15:26:31 |
