| 22 May 2021 |
 maralorn | sterni: cdepillabout: I am wondering how we should go about problems were people fix stuff upstream and then we have to decide if we workaround it or bump our hackage snapshot to fix our build error. I wish there was a solution to somehow bump only this one package … | 18:55:42 |
 sterni (he/him) | this is the moment where I go I told you so right? :p | 18:56:07 |
| sterni (he/him) | it's a bit unfortunate, but I think we may also get away with bumping the hackage pin as well | 18:56:26 |
| sterni (he/him) | other than that we can just use overrideSrc in this case I'm pretty sure | 18:56:53 |
| sterni (he/him) | I checked earlier doing a bump of hackage only has a sizeable diff, but it's hard to say if it'd break anything ofc | 18:57:24 |
| maralorn | The question is if we could (and want) introduce a distinction between the hackage-snapshot used for generation and the hackage-snapshot used for taking prefered-versions. | 18:59:02 |
| maralorn | Oh, actually. No that I phrase it that way, I don‘t think it would be that hard. | 18:59:40 |
| sterni (he/him) | we could probably do the same thing as for stackage and just generate a list of all the versions from the snapshot | 18:59:46 |
| maralorn | But it certainly comes with a complexity cost. | 18:59:54 |
| sterni (he/him) | then we could update the snapshot independently of that without regenerating the lsit | 19:00:02 |
| maralorn | In reply to @sternenseemann:systemli.org
we could probably do the same thing as for stackage and just generate a list of all the versions from the snapshot That will generate a lot of additional noise in the git-repo. | 19:00:26 |
| sterni (he/him) | I also wonder if there would be any performance cost on hackage2nix | 19:00:27 |
| maralorn | sterni: The update-hackage script passes the hackage version and the preferred-versions separately to hackage2nix. So it would be pretty easy to give it different preferred versions. | 19:02:40 |
| sterni (he/him) | oh right forgot that was a thing | 19:05:25 |
|  Valentin Golev joined the room. | 20:47:54 |
| Valentin Golev | Redacted or Malformed Event | 20:48:07 |
| Valentin Golev | Redacted or Malformed Event | 20:49:01 |
| maralorn | In reply to @maralorn:maralorn.de
sterni: The update-hackage script passes the hackage version and the preferred-versions separately to hackage2nix. So it would be pretty easy to give it different preferred versions. That way we could also do the thing, that we had considered, where we can keep the hackage snapshot up-to-date on stable without bumping any packages. | 21:02:08 |
| sterni (he/him) | right indeed | 21:05:06 |
| sterni (he/him) | just got to find a clean way to track the preferred-versions file while also making it editable | 21:05:49 |
| maralorn | sterni: I don‘t think we need it editable. We can always override single versions via the yaml config. | 21:06:41 |
| maralorn | Huh, now that I think about it … | 21:07:54 |
| maralorn | I don‘t even think we need to track the latest hackage snapshot in nixpkgs. We only need to track which snapshot we use for preferred_versions. | 21:08:38 |
| maralorn | Would make the update script impure though | 21:09:39 |
| sterni (he/him) | but don't we want to keep preferred_versions and bump a single packae | 21:09:42 |
| sterni (he/him) | * but don't we want to keep preferred_versions and bump a single package? | 21:09:47 |
| maralorn | But I think only theoretically. | 21:09:57 |
| maralorn | sterni: Yes, what we would do is this a) use the pinned snapshot for preferred_versions b) use a freshly pulled snapshot from hackage for running hackage2nix c) for packages where we want the version to be newer than the preferred_version we pin the package in the yaml file. | 21:11:47 |
| maralorn | We already do a). | 21:11:56 |
| maralorn | But b) is necessary for c) to work, because otherwise hackage2nix would possible not know about the newer package version. | 21:12:19 |
