Newest at the top
| 2026-04-10 09:32:24 +0000 | <merijn> | And there's often not a really big reason to adopt the bleeding edge while that happens |
| 2026-04-10 09:32:05 +0000 | <merijn> | It generally takes 9 months to a year for a new GHC version to percolate through to for the majority of the ecosystem to |
| 2026-04-10 09:31:58 +0000 | <gentauro> | tomsmeding: yeah, I road that piece of documentation and I didn't get any wiser … |
| 2026-04-10 09:31:13 +0000 | <Milan_Vanca> | That is one way granted |
| 2026-04-10 09:30:46 +0000 | <merijn> | And then all your --allow-newer problems should hopefully disappear |
| 2026-04-10 09:29:16 +0000 | <merijn> | I'd probably pick 9.10 or 9.12 atm |
| 2026-04-10 09:28:57 +0000 | <merijn> | Milan_Vanca: at any rate, unless there is a specific bug blocking you OR new feature you need from the latest GHC I would never recommend using the latest version |
| 2026-04-10 09:28:36 +0000 | <Milan_Vanca> | you have sandbox and then solve dependencies there... |
| 2026-04-10 09:28:06 +0000 | <merijn> | Milan_Vanca: Most Python tooling just looks at your flat list of dependencies and goes "check, lemme use that" |
| 2026-04-10 09:28:00 +0000 | <Milan_Vanca> | Okey I mean poetry |
| 2026-04-10 09:27:43 +0000 | <merijn> | Milan_Vanca: Oh god no |
| 2026-04-10 09:27:37 +0000 | <Milan_Vanca> | merijn: I read your note about building DAG and trying to satisfy all dependencies.. But python must do the same |
| 2026-04-10 09:27:34 +0000 | <merijn> | Milan_Vanca: 2) unlike python's "everything is globally installed" OR "you gotta manually sandbox each project", cabal creates "on-demand" per-project projections of everything installed globally |
| 2026-04-10 09:25:26 +0000 | <merijn> | I personally always used "second to latest" |
| 2026-04-10 09:25:14 +0000 | <merijn> | I would not use the latest GHC, tbh |
| 2026-04-10 09:25:07 +0000 | <merijn> | Milan_Vanca: Right, so that's bleeding edge :p |
| 2026-04-10 09:25:00 +0000 | <merijn> | that means that if a package claims to work (no upper bound), but doesn't you break everything |
| 2026-04-10 09:24:57 +0000 | <Milan_Vanca> | merijn: No I use ghc 9.14 and many libs just don't support that yet. |
| 2026-04-10 09:24:39 +0000 | <merijn> | Milan_Vanca: Some important differences between cabal and python's tooling: 1) cabal creates a DAG of dependencies with version constraints and tries to solve it to find a combination of dependency versions that makes every transitive dependency happy |
| 2026-04-10 09:24:02 +0000 | <Milan_Vanca> | tomsmeding: but can't we say in cabal to cap some max version and thus no need for fork? |
| 2026-04-10 09:23:27 +0000 | <merijn> | OR you're on the bleeding edge |
| 2026-04-10 09:23:18 +0000 | <merijn> | Milan_Vanca: If you have to "allow-newer" many things, that's a sign you're using unmaintained/out of date dependencies |
| 2026-04-10 09:23:15 +0000 | <Milan_Vanca> | merijn: Not yet thank you for link |
| 2026-04-10 09:22:26 +0000 | <merijn> | Not to mention in python everything's just dictionaries of strings to values and no guarantees of what fields exist. Which means that using the wrong version very often kinda seems to work, if you're lucky |
| 2026-04-10 09:22:18 +0000 | <Milan_Vanca> | merijn: :D Good point I think |
| 2026-04-10 09:21:14 +0000 | <merijn> | Milan_Vanca: https://pvp.haskell.org |
| 2026-04-10 09:20:55 +0000 | <merijn> | Milan_Vanca: Have you read the PVP? |
| 2026-04-10 09:20:29 +0000 | <merijn> | Milan_Vanca: cabal is fundamentally different from python's dependencies management approach |
| 2026-04-10 09:20:25 +0000 | <tomsmeding> | fixing a missing cap requires forking the project, whereas fixing an over-restrictive cap can be done with allow-newer or by asking for a non-maintainer update of the metadata on hackagte |
| 2026-04-10 09:19:51 +0000 | <tomsmeding> | well, no |
| 2026-04-10 09:19:51 +0000 | <merijn> | They keep reinventing their build tools every year too, each time with the same problems |
| 2026-04-10 09:19:42 +0000 | <tomsmeding> | > Anyone can fix a missing cap, but users cannot fix an over restrictive cap |
| 2026-04-10 09:19:39 +0000 | <tomsmeding> | from the tldr in that article: |
| 2026-04-10 09:19:32 +0000 | <merijn> | Milan_Vanca: Python's ecosystem is constantly broken, so I would ignore anything they say |
| 2026-04-10 09:19:03 +0000 | <merijn> | I don't know what "flt structure oif dependencies" means |
| 2026-04-10 09:15:16 +0000 | <Milan_Vanca> | To my knowledge cabal/ghc too uses "flat" structure of dependencies same as python, so arguments should be applicable. |
| 2026-04-10 09:14:40 +0000 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 276 seconds) |
| 2026-04-10 09:12:23 +0000 | <Milan_Vanca> | I don't want to start flame war I am asking in good faith. Like now I just manually "allow-newer" for every dependency but it tiresome |
| 2026-04-10 09:11:32 +0000 | danza | (~danza@user/danza) danza |
| 2026-04-10 09:11:22 +0000 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2026-04-10 09:10:04 +0000 | <Milan_Vanca> | Anyway I want to ask different question. I have noticed many libs (alost all) on hackage to specify upper bound for its dependencies. This article https://iscinumpy.dev/post/bound-version-constraints/ says libs should not do that. Do you think information in that article is relevant for haskell packages? |
| 2026-04-10 09:03:39 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:84a:b712:d1d0:a9d4) synchromesh |
| 2026-04-10 09:02:36 +0000 | <Milan_Vanca> | data S = S {x :: Int} |
| 2026-04-10 09:01:38 +0000 | <Milan_Vanca> | Do I understand that correctly that there is difference between exporting module M (S(S, x)) where .. and module M (S(S), x) where |
| 2026-04-10 08:59:32 +0000 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-04-10 08:58:58 +0000 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 244 seconds) |
| 2026-04-10 08:57:15 +0000 | GdeVolpi1 | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
| 2026-04-10 08:42:23 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-04-10 08:42:04 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-04-10 08:39:46 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:84a:b712:d1d0:a9d4) (Ping timeout: 248 seconds) |