2026/01/29

Newest at the top

2026-01-29 16:24:03 +0100 <ags> And, yes, I'm using `ghcup` for everything.
2026-01-29 16:22:59 +0100 <ags> comerijn: Yeah, Michael Snoyman is quite prolific :)
2026-01-29 16:22:44 +0100hakutaku(~textual@chen.yukari.eu.org)
2026-01-29 16:16:42 +0100st_aldini(~Thunderbi@136.48.46.187) (Quit: st_aldini)
2026-01-29 16:15:29 +0100spew(~spew@user/spew) (Ping timeout: 260 seconds)
2026-01-29 16:13:43 +0100spew_(~spew@user/spew) spew
2026-01-29 16:13:17 +0100 <comerijn> That only applies to the arch toolchain, though. If you use ghcup things should "Just Work (TM)"
2026-01-29 16:13:04 +0100Googulator91Googulator
2026-01-29 16:12:44 +0100 <comerijn> ags: Entirely unrelatedly: Be careful with Haskell tools on Arch as the official arch packages ship in a way where the default use of tools is horribly broken
2026-01-29 16:11:26 +0100Lycurgus(~juan@user/Lycurgus) Lycurgus
2026-01-29 16:10:51 +0100 <comerijn> Which is of course perfectly neutral and not opinionated on the matter at all :p
2026-01-29 16:10:33 +0100 <comerijn> ags: See also: https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07
2026-01-29 16:10:24 +0100Zemy_(~Zemy@72.178.108.235) (Ping timeout: 244 seconds)
2026-01-29 16:09:58 +0100 <comerijn> In practice, having used lots of Snoyman libraries in the past I never had issues using them via cabal, because they're "just" cabal packages anyway
2026-01-29 16:09:27 +0100 <Clint> no, sorry for the confusion
2026-01-29 16:09:21 +0100 <comerijn> ags: FYI, Yesod was made by the same person/group that made stack, so obviously they would recommend stack ;)
2026-01-29 16:08:55 +0100 <ags> Clint: Ah, okay, I misunderstood you. I thought you were talking about the Shakespearean templates.
2026-01-29 16:08:34 +0100danza(~danza@user/danza) danza
2026-01-29 16:08:15 +0100Zemy(~Zemy@2600:100c:b0a6:f645:6069:a8ff:fe47:a76d)
2026-01-29 16:08:09 +0100 <comerijn> ags: So the benefits are basically out the window, the second you manually add a dependency from outside stackage into the mix
2026-01-29 16:07:47 +0100 <comerijn> ags: The basic premise of stack is to resolve everything via LTS snapshots of hackage (and enforcing all versions within those to work together). This does not actually solve the underlying problem which gets most people in trouble (i.e. "I'm trying to use an ancient package that hasn't been updated and ends up being incompatible with everything else")
2026-01-29 16:06:55 +0100 <Clint> ags: my knowledge may be out of date. there used to be a `yesod init` subcommand but it was gutted and replaced with a note to use `stack new` instead.
2026-01-29 16:04:07 +0100 <ags> Clint: Hm, okay, so far everything has been working without stack but I haven't finished the "Yesod Book" yet. Maybe I'll run into the issue you are mentioning later on.
2026-01-29 15:59:50 +0100 <ags> gentauro: No, not yet unfortunately. I'm using Arch Linux.
2026-01-29 15:58:49 +0100 <gentauro> ags: what's your OS if I may ask? Any chance you use `nixOS`?
2026-01-29 15:58:48 +0100traxex(traxex@user/traxex) (Ping timeout: 265 seconds)
2026-01-29 15:57:30 +0100 <Clint> if you want the yesod templates i think you need to use stack
2026-01-29 15:53:11 +0100 <ags> Okay, thank you for the explanation. I'm considering starting a new project with `yesod`. The documentation recommends `stack` but I'd like to stick to "standard tools" if possible.
2026-01-29 15:50:21 +0100remedan(~remedan@78-80-95-79.customers.tmcz.cz) remedan
2026-01-29 15:49:59 +0100remedan(~remedan@78-80-95-79.customers.tmcz.cz) (Quit: Bye!)
2026-01-29 15:48:25 +0100cyphase(~cyphase@user/cyphase) cyphase
2026-01-29 15:44:23 +0100 <tomsmeding> and for commonly-used packages, the bounds are typically good, meaning that you only run into this for unpopular packages
2026-01-29 15:44:15 +0100 <__monty__> ags: This is a criticism of the PVP, it's worth reading even though the author comes to the wrong conclusion IMO, https://ro-che.info/articles/2013-10-05-why-pvp-doesnt-work.html
2026-01-29 15:43:47 +0100 <tomsmeding> however, in practice this only really happens due to missing upper bounds, i.e. package A declares it will support all versions of B, but a breaking change in B actually does break A
2026-01-29 15:42:48 +0100 <tomsmeding> dependency bounds on packages are not always fully accurate, so it is possible that cabal gives you a set of dependencies that is incompatible with each other
2026-01-29 15:40:59 +0100 <ags> Is there a technical reason I wouldn't want dependency version resolution?
2026-01-29 15:40:45 +0100timide(~timide@user/timide) timide
2026-01-29 15:40:14 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2026-01-29 15:37:08 +0100weary-traveler(~user@user/user363627) user363627
2026-01-29 15:35:30 +0100 <__monty__> Use whatever the project prefers. For new projects use Cabal unless you absolutely don't want dependency version resolution.
2026-01-29 15:33:56 +0100 <haskellbridge> <Morj> Cabal docs and interface are still frustrating to me
2026-01-29 15:33:10 +0100 <haskellbridge> <Morj> Always
2026-01-29 15:32:07 +0100 <ags> When should I use `stack` over `cabal` in 2026?
2026-01-29 15:25:39 +0100chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2026-01-29 15:25:38 +0100bggd__bgg
2026-01-29 15:18:37 +0100cyphase(~cyphase@user/cyphase) (Ping timeout: 264 seconds)
2026-01-29 15:09:42 +0100cyphase(~cyphase@user/cyphase) cyphase
2026-01-29 15:02:32 +0100chromoblob(~chromoblo@user/chromob1ot1c) (Ping timeout: 240 seconds)
2026-01-29 15:02:00 +0100_d0t(~{-d0t-}@user/-d0t-/x-7915216) {-d0t-}
2026-01-29 15:01:09 +0100_d0t(~{-d0t-}@user/-d0t-/x-7915216) (Remote host closed the connection)