| 4 Nov 2024 |
 sterni (he/him) | you could try reversing the order of the args and manually added set | 18:05:07 |
| sterni (he/him) | i think it should work then that it is only affected by explicit input | 18:05:24 |
 lxsameer | but it would be possible to do it in a derivation that you're directly working with (e.g. packages.default, the main derivation of the project). right? | 18:10:50 |
| lxsameer | how often do we update the all-cabal-hashes on nixos-unstable? | 18:28:24 |
|  @asymmetric:matrix.dapp.org.uk left the room. | 19:19:49 |
 maralorn | In reply to @lxsameer:matrix.org
but it would be possible to do it in a derivation that you're directly working with (e.g. packages.default, the main derivation of the project). right? I think with that brute force hammer that might be problematic. | 23:18:46 |
| maralorn | In reply to @lxsameer:matrix.org
how often do we update the all-cabal-hashes on nixos-unstable? Well, normally we do that every one or two weeks. But due to lack of maintainer time the frequency dropped quite severely lately. | 23:19:39 |
| lxsameer | In reply to @maralorn:maralorn.de
I think with that brute force hammer that might be problematic. What other option do we have? | 23:22:24 |
| lxsameer | In reply to @maralorn:maralorn.de
Well, normally we do that every one or two weeks. But due to lack of maintainer time the frequency dropped quite severely lately. I can take care of it. Should i directly taget the unstable branch or staging? | 23:22:59 |
| maralorn | Not sure. Need to think. | 23:24:19 |
| lxsameer | Cool let me know then | 23:25:48 |
| maralorn | In reply to @lxsameer:matrix.org
I can take care of it. Should i directly taget the unstable branch or staging? Well, the bumping is the easy part. The problem is that after the bump we refresh the derivation in hackage-packages.nix and then need fix all the build errors which arise. While we do that we avoid to bump the pin again because that could introduce new errors before we can merge the branch (haskell-updates) into master. So we iterate over PRs like this: https://github.com/NixOS/nixpkgs/pull/351154 | 23:26:24 |
| maralorn | Well, the best idea I have from the top of my head is what I suggested a few days ago. | 23:30:02 |
| maralorn | Which is something like: | 23:30:21 |
| lxsameer | Cooool. I'll give it a shot | 23:30:39 |
| maralorn |
- For every package you override with overrideCabal in your generated overlay you set something like
passthru.auto-added = true.
| 23:31:48 |
| maralorn |
- You override mkDerivation to iterate over all haskell inputs, inspect whether they have a value
auto-added which is true and if yes you a) also set that value on this derivation and b) disable tests and profiling builds.
| 23:33:36 |
| maralorn | Admittedly that’s a bit dishonest by me because that addresses the issue I was concerned about (cache.nixos.org) but not necessarily the one you wer concerned about (enabling test for the main package you are trying to build.) | 23:35:12 |
| maralorn | But I guess this method can be extended by introducing a second variable. auto-build-target and stopping the propagation of auto-added when auto-build-target is set. | 23:36:25 |
| maralorn | A bit gnarly I admit, but it seems like it’s doable. | 23:37:06 |
| 5 Nov 2024 |
| lxsameer | Good i'll implement it tomorrow. Thank you | 00:00:20 |
| lxsameer | In reply to @maralorn:maralorn.de
Well, the best idea I have from the top of my head is what I suggested a few days ago. Quick question, a passthru from pkg A that depends on B and B to C will propagates from A to C right? | 12:23:03 |
| maralorn | Ah, wait. | 13:20:59 |
| maralorn | "passthru" is nix derivation speak for "if you set a value here (in the derivation description) it will be exposed from the final derivation". passthru has a priori nothing to do with passing values to dependencies. I just had the idea to abuse them for that. | 13:29:02 |
| lxsameer | yeah i know that much, but the thing i didn't understand is that how it is going to help us disable the test for indirect dependencies? | 13:33:14 |
| maralorn | By my step 2. up there. That should propagate the passthru flag from A to C. | 13:40:57 |
| lxsameer | I don't get it. let's use a concrete example. in the list of overrides, I override hasql and set a passthru A to true. In the mkDerivation iterate through inputs and if the input has the the A passthru I disable the tests and profiling and set A as well. But hasql's mkDerivation will have the passthru and not the inputs | 13:54:48 |
| lxsameer | right | 13:55:00 |
| maralorn | But the inputs of hasql don’t need overriding, unless they have any input which is already overriden and they would get their flag propagated from there. | 14:07:23 |
| maralorn | The aim is explicitely not to disable tests on dependencies. We only need to disable tests on reverse dependencies of anything we override. | 14:08:30 |
