Newest at the top
| 2026-04-10 09:51:26 +0000 | <Milan_Vanca> | merijn: If I "allow-newer" then the "worst" case is that type's won't match and it just won't compile right? Should I also expect runtime bugs? I mean there is always posibility to use "untested" version. |
| 2026-04-10 09:49:38 +0000 | <merijn> | Milan_Vanca: It's not so much about not using latest because of being buggy, but just because dealing with the ecosystem not being instantly ready is too much of a hassle |
| 2026-04-10 09:48:49 +0000 | <merijn> | Oh, I'm not saying you shouldn't use/test the latest version. Just be aware that that comes with a lot of --allow-newer overrides until adoption goes wider :p |
| 2026-04-10 09:44:58 +0000 | <Milan_Vanca> | But also maybe I like to live on edge...There is also .NET MAUI "production ready" for few years but still unusable... |
| 2026-04-10 09:43:41 +0000 | <Milan_Vanca> | merijn: Your stance about not using latest version are quite strong. And I kind of agree when one develops mission critical application. But also somebody needs to use and test latest version to iron out all issues. I don't want to believe that "Suitable for use/LTS" is really that buggy. |
| 2026-04-10 09:34:36 +0000 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2026-04-10 09:33:04 +0000 | <gentauro> | anyway, just renamed the field and no probs :) |
| 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} |