| 26 May 2021 |
 sterni (he/him) | which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent) | 12:40:14 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
The problem is that this would be a moderately invasive operation on cabal2nix/hackage2nix and none of us maintainers has a lot of free time or familarity with the code base. So any outside help on this topic would be appreciated. also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) | 12:41:21 |
 maralorn | In reply to @sternenseemann:systemli.org
also this is yet another layer of complexity added to the process we have currently which we already made quite a bit more involved than before (in terms of moving / interacting parts, not necessarily usability) I am not really afraid of that. Yes, automation brings complexity but if done well complexity covered by the code is complexity we developers don't need to deal with. | 12:57:56 |
| sterni (he/him) | It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing | 12:59:23 |
| sterni (he/him) | at least that is what I am afraid of we'll reach | 12:59:32 |
| maralorn | In reply to @sternenseemann:systemli.org
which has the same outcome really, but avoids blocking the channel by accident (I believe cachix is a channel constituent) If cachix builds on our branch and not on master then in 99% of cases that means that cachix is already broken on master. So in a sense that's not our fault. It should be fixed as soon as possible but that's orthogonal to our PR. Besides build fails channel advancement depends on all package build being finished so that does not have a lot to do with cachix. | 13:02:32 |
| sterni (he/him) | In reply to @maralorn:maralorn.de
If cachix builds on our branch and not on master then in 99% of cases that means that cachix is already broken on master. So in a sense that's not our fault. It should be fixed as soon as possible but that's orthogonal to our PR. Besides build fails channel advancement depends on all package build being finished so that does not have a lot to do with cachix. not about failures, build times | 13:03:02 |
| sterni (he/him) | like the channel will be unable to advance until we have rebuild enough of the haskell packages set to build cachix | 13:03:24 |
| sterni (he/him) | if it takes a day to rebuild we can just do it on the branch and have the cache fully populated already when we merge | 13:03:46 |
| maralorn | In reply to @sternenseemann:systemli.org
It's not just code complexity it's also semantic complexity you have to kinda be aware of when contributing We actually already have the case that broken flags are kinda opaque to drive by contributers. Sometimes packages are marked broken without an easily understandable reason and cdepillabout pings me to figure out why. (this is more of a statement of fact. I am not arguing in any specific direction.) | 13:05:26 |
| maralorn | In reply to @sternenseemann:systemli.org
like the channel will be unable to advance until we have rebuild enough of the haskell packages set to build cachix I understand your point, but this has nothing to do with cachix. The channel will only advance when all jobs in the evaluation are finished. This includes all haskellPackages. Or are we talking about unstable-small and cachix is included in that? I assume it isn't. | 13:07:18 |
| maralorn | In reply to @sternenseemann:systemli.org
if it takes a day to rebuild we can just do it on the branch and have the cache fully populated already when we merge I am torn on this point. The fact is if our merge would mean a 500+ rebuild we would have to target staging. (and haskell builds aren't the fastest.) So we should basically adhere to that. Otoh the longer we push off a merge the higher is the risk that hydra does redundant additional work. | 13:10:15 |
| sterni (he/him) | the channel will advance when all constituents of a certain aggregate job are built not when all of nixpkgs is built | 13:11:13 |
| sterni (he/him) | and cachix is part of the nixpkgs:unstable job | 13:11:23 |
| sterni (he/him) | https://hydra.nixos.org/job/nixpkgs/trunk/unstable | 13:11:59 |
