Newest at the top
| 2026-04-10 10:04:23 +0000 | <Milan_Vanca> | really? I didn't know that |
| 2026-04-10 10:04:03 +0000 | <merijn> | Although rust's stuff is heavily cabal inspired afaik |
| 2026-04-10 10:03:47 +0000 | <merijn> | and maybe Rust? |
| 2026-04-10 10:03:42 +0000 | <merijn> | haskell's :p |
| 2026-04-10 10:03:13 +0000 | Enrico63 | (~Enrico63@host-212-171-80-94.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-04-10 10:02:59 +0000 | <Milan_Vanca> | merijn: Anyway when you said not to look up to python packaging. Are there other systems you might recommend? |
| 2026-04-10 10:01:43 +0000 | Square3 | (~Square@user/square) Square |
| 2026-04-10 09:55:53 +0000 | craunts795335385 | (~craunts@152.32.99.2) |
| 2026-04-10 09:55:17 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2026-04-10 09:54:47 +0000 | craunts795335385 | (~craunts@152.32.99.2) (Client Quit) |
| 2026-04-10 09:53:23 +0000 | <Milan_Vanca> | Yeah.. runtime bugs are always possible.. I should start writing more tests :D |
| 2026-04-10 09:52:39 +0000 | craunts795335385 | (~craunts@152.32.99.2) |
| 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 |