| 22 Apr 2025 |
 emily | "if it hurts, do it more often" etc. | 12:23:24 |
 Teo (he/him) | Perhaps the issue here was that you wanted the solver to pick some flags and nixpkgs doesn't have a solver? Not sure exactly what he's alluding to tho | 12:24:27 |
|  mightybyte joined the room. | 12:27:35 |
|  @ihar.hrachyshka:matrix.org joined the room. | 12:33:31 |
 alexfmpe | * But it's not an orthogonal layer we can just be agnostic to. If they have some package deep in the dependency chains that is broke but only the tests expose it, stackage will happily base other package versions around it and then we need to undo a part of that
EDIT: me wrong. Stackage does run (native) test suites, they just don't patch stuff | 12:37:03 |
| alexfmpe | * It's insane to me they don't run test suites
EDIT: me wrong. Stackage does run (native) test suites, they just don't patch stuff | 12:37:51 |
| Teo (he/him) | Redacted or Malformed Event | 12:44:39 |
| alexfmpe | In reply to @alexfmpe:matrix.org
apparently I'm wrong, stackage site claims they do run test suites Think I see where I got confused. They do run test suites and also install c libraries and stuff on the docker image for libs that do need that
What they don't seem to do is spin up separate processes or other crazy stuff we get up to when running the test suites | 12:48:51 |
| alexfmpe | e.g. postgres libs test suites are disabled | 12:49:05 |
| alexfmpe | https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml#L8694 | 12:49:08 |
| alexfmpe | Oh heh TIL they also have our silly test-suite-induced-cycle issues | 12:50:33 |
| emily | FWIW, AIUI we used to track Stackage nightly but then stopped. it came up a while ago. I think maralorn had things to say about it. | 12:55:17 |
 maralorn | I am in favor of tracking nightly. We simply didn’t have the energy to frontload the flag day. | 12:59:57 |
| emily | is the flag day b/c jumping from current LTS to current nightly will effectively be the work of an LTS bump? | 13:01:09 |
| alexfmpe | I assume that becomes closer to the truth the closer nightly is to become new LTS? | 13:06:06 |
| alexfmpe | Or is nightly just very much broken in the early days? | 13:08:44 |
| maralorn | Its comparable yes. | 13:13:41 |
| maralorn | It’s often quite a lot smaller than LTS in the beginning. | 13:14:07 |
| emily | and I assume the current Nightly is closer to the next LTS than the one we just bumped to? 😆 | 13:14:33 |
| maralorn | correct | 13:15:57 |
| maralorn | Bumping the stackage snapshot generally means bumping the ghc major version that has friction no matter how early or late we do it. | 13:16:41 |
| alexfmpe | In reply to @maralorn:maralorn.de
It’s often quite a lot smaller than LTS in the beginning. Huh smaller building set or smaller breakage when bumping to it? | 13:19:55 |
| emily | I assumed the former | 13:23:27 |
| alexfmpe | Huh yeah the other doesn't make much sense disregarf | 13:26:13 |
| alexfmpe | * Huh yeah the other doesn't make much sense disregard | 13:26:21 |
| emily | right, I actually first assumed the latter and then realized it must be the former :) | 13:27:21 |
| emily | anyway I guess returning to the actual original point that was raised, I do feel like things are always going to be inherently difficult on some level unless the practices of the Haskell ecosystem itself change. not sure maintainers of packages supporting older and older GHCs is the answer – back in the day I remember it rather painful and it feeling like a relief to be able to rip out an old version, though maybe there's less CPP these days. ideally GHC would make fewer gratuitous breaking changes or at least do them more gracefully… (though again I understand that it's not as bad as it used to be) | 13:29:14 |
| maralorn | We don’t need a lot of back-compat. Maintainers should imo support [Stackage LTS … Stackage Nightly … Hackage Head] | 13:31:15 |
|  Albert Larsan joined the room. | 13:45:27 |
 @malteneuss:matrix.org | If you have the time, could you post this idea to https://discourse.haskell.org/t/how-much-effort-does-backwards-compatibility-require-from-library-authors/11584/79 to further the discussion on this possible direction? (will get more credibility/attention coming from you) | 13:49:57 |
