| 2025-01-16 00:00:48 +0100 | <haskellbridge> | <magic_rb> if have a record such as "Foo { bar :: Text }" then I generate a lens called "bar", i cannot construct the record with "Foo { bar = "foobar" }". Is there any way around this? it complains about a ambiguous reference, though i dont see how he lens is a valid candidate on the LHS of "bar = "foobar"" anyway |
| 2025-01-16 00:02:01 +0100 | mange | (~user@user/mange) mange |
| 2025-01-16 00:07:18 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-16 00:08:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:09:06 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-16 00:10:20 +0100 | sord937_ | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937_) |
| 2025-01-16 00:12:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 00:16:37 +0100 | <haskellbridge> | <sm> Guest71: I probably wouldn't use a Hackage category or tag for this, I'd rely on a common package name prefix instead |
| 2025-01-16 00:17:25 +0100 | <haskellbridge> | <sm> if you are able to publish as one package, it will simplify maintenance hugely |
| 2025-01-16 00:17:48 +0100 | <haskellbridge> | <sm> maintenance and further packaging |
| 2025-01-16 00:19:50 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-16 00:20:30 +0100 | <haskellbridge> | <magic_rb> got it, somehow "DuplicateRecordFields" did it |
| 2025-01-16 00:23:00 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2025-01-16 00:23:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:25:17 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-16 00:28:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-16 00:29:48 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 272 seconds) |
| 2025-01-16 00:31:11 +0100 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2025-01-16 00:32:16 +0100 | <Guest71> | sm: Thanks for your input. I was planning to use a prefix already, but I was wondering if there were additional conventions around grouping packages. |
| 2025-01-16 00:32:16 +0100 | <Guest71> | On the topic of monopacking: I figured users would prefer to be able to pick micropackages as to avoid pulling in dependencies for pieces of the project they were not planning to use (reduce binary size and total logic surface). Am I wrong about this? |
| 2025-01-16 00:33:39 +0100 | saulosilva | (~saulosilv@181.216.220.107) (Quit: Client closed) |
| 2025-01-16 00:39:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:39:47 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-16 00:41:00 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-01-16 00:41:43 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 00:42:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2025-01-16 00:42:03 +0100 | ljdarj1 | ljdarj |
| 2025-01-16 00:43:39 +0100 | Guest69 | (~Guest69@2601:642:4103:1b0:a477:319d:e581:377a) |
| 2025-01-16 00:43:40 +0100 | <haskellbridge> | <sm> you're not wrong, sometimes it is worth providing separate packages for that reason. But there's a maintenance and packaging cost to be carried for everymore, fewer larger packages will be less work |
| 2025-01-16 00:44:21 +0100 | <haskellbridge> | <sm> how many packages are you contemplating ? |
| 2025-01-16 00:46:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 00:46:07 +0100 | mrmr155334346318 | (~mrmr@user/mrmr) mrmr |
| 2025-01-16 00:46:20 +0100 | <jackdk> | Guest71: and also, how large are these packages (and their combination)? |
| 2025-01-16 00:46:20 +0100 | <haskellbridge> | <sm> also sometimes even users prefer one or a few big packages, even if it's not optimal in bandwidth/disk space, it simplifies their life |
| 2025-01-16 00:48:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:51:08 +0100 | <Guest71> | sm: Around 7 at the moment, but could potentially grow (basically there is a collection of implementations for a large interface, each implementation is its own repo, eventually more could be added for more use-cases). I am not too concerned about maintenance burden because the plan is to build a CI/CD pipeline to take care of that. Ideally I'd do |
| 2025-01-16 00:51:08 +0100 | <Guest71> | that once, tweak slightly for each repo and then never think about it again. Should I be worried about something? |
| 2025-01-16 00:51:09 +0100 | <Guest71> | jackdk: ~10 kloc a piece. For 7 repos that would be ~70 kloc. |
| 2025-01-16 00:51:38 +0100 | <geekosaur> | you might look at amazonka for an example of how to do it? |
| 2025-01-16 00:52:28 +0100 | <jackdk> | Amazonka IMHO is a special case because so much of it is autogenerated. But even there we eventually hope to trial multiple cabal sublibraries since we have to update the whole universe in lockstep anyway |
| 2025-01-16 00:54:03 +0100 | <jackdk> | I'm not sure I'd call a 10kLoC package a "micropackage". That's no `left-pad` or `is-number`, and the PVP implications for a monopackage are not ideal: any backwards-incompatible change in one will bump PVP major version and make anyone not depending on the changed package go back and check for other breakage. |
| 2025-01-16 00:54:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-16 00:55:22 +0100 | <jackdk> | That said, now that I've read Guest71's question properly, breaking up an interface to a large API is probably a reasonable case for having at least multiple distinct sublibraries if not distinct packages (depend on how much lockstep updating you need to do if something changes) |
| 2025-01-16 00:57:23 +0100 | lol_ | (~lol@2603:3016:1e01:b9c0:49df:554e:a17b:a07c) |
| 2025-01-16 00:58:28 +0100 | <jackdk> | Is there any reason a monorepo with a cabal.project won't work for you here? That would save you building a lot of CI machinery, which is time you can spend writing more Haskell |
| 2025-01-16 00:59:28 +0100 | <jackdk> | Amazonka is 3.8×10⁶ LoC, the vast majority of which is autogenerated, and it works fine enough |