| 22 May 2021 |
 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 |
| sterni (he/him) | ah yeah right that works | 21:12:30 |
| maralorn | Two downsides: 1) updating might get a bit more expensive because it always looks for a fresh snapshot. 2) callHackage can only use versions in the pinned snapshot. | 21:15:14 |
| maralorn | But 2) is not worse than what we do now. | 21:15:38 |
| sterni (he/him) | it's the same as we do now? | 21:20:40 |
| maralorn | Yes | 21:20:57 |
| maralorn | I just was briefly considering pinning 2 hackage-versions one for the preferred versions and one for generating + callHackage. Then it would be absolutely frictionless to update the one for callHackage, e.g. on stable regularly. | 21:22:19 |
