Newest at the top
| 2025-01-16 01:02:39 +0100 | <Guest71> | jackdk: monopackage would work. I'm just thinking that from a UX point of view users in general do not want to pull stuff they will not use: larger binaries, larger logic surface means potentially more room to misuse/bugs, potentially worse test coverage, and as you said, now your API is less stable (more moving parts), |
| 2025-01-16 01:00:51 +0100 | jcarpenter2 | (~lol@2603:3016:1e01:b9c0:794b:ce9f:2a3d:41ae) (Ping timeout: 252 seconds) |
| 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 |
| 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:57:23 +0100 | lol_ | (~lol@2603:3016:1e01:b9c0:49df:554e:a17b:a07c) |
| 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:54:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 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: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:51:38 +0100 | <geekosaur> | you might look at amazonka for an example of how to do it? |
| 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: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: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:48:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 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:46:20 +0100 | <jackdk> | Guest71: and also, how large are these packages (and their combination)? |
| 2025-01-16 00:46:07 +0100 | mrmr155334346318 | (~mrmr@user/mrmr) mrmr |
| 2025-01-16 00:46:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 00:44:21 +0100 | <haskellbridge> | <sm> how many packages are you contemplating ? |
| 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:43:39 +0100 | Guest69 | (~Guest69@2601:642:4103:1b0:a477:319d:e581:377a) |
| 2025-01-16 00:42:03 +0100 | ljdarj1 | ljdarj |
| 2025-01-16 00:42:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2025-01-16 00:41:43 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 00:41:00 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-01-16 00:39:47 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-16 00:39:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:33:39 +0100 | saulosilva | (~saulosilv@181.216.220.107) (Quit: Client closed) |
| 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: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:31:11 +0100 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2025-01-16 00:29:48 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 272 seconds) |
| 2025-01-16 00:28:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-16 00:25:17 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-16 00:23:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:23:00 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2025-01-16 00:20:30 +0100 | <haskellbridge> | <magic_rb> got it, somehow "DuplicateRecordFields" did it |
| 2025-01-16 00:19:50 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-16 00:17:48 +0100 | <haskellbridge> | <sm> maintenance and further packaging |
| 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: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:12:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 00:10:20 +0100 | sord937_ | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937_) |
| 2025-01-16 00:09:06 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-16 00:08:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 00:07:18 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-16 00:02:01 +0100 | mange | (~user@user/mange) mange |
| 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-15 23:57:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-15 23:53:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |