Newest at the top
| 2025-01-16 01:07:02 +0100 | <Guest71> | sm: I suppose that is always a possibility. But assuming I fix that for one package, then I would just apply the diff to the rest and be done, no? |
| 2025-01-16 01:06:09 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f02edd754543fe6660f.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-01-16 01:05:28 +0100 | <jackdk> | But I would also look at sublibraries which _should_ be usable everywhere now? Amazonka doesn't use them (yet?) because it predates them being widely available. Then you have a larger initial download but everything's in one place. Users still wouldn't compile things they don't need. |
| 2025-01-16 01:05:24 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2025-01-16 01:04:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:03:50 +0100 | ljdarj1 | ljdarj |
| 2025-01-16 01:03:49 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-01-16 01:03:37 +0100 | <jackdk> | Guest71: I mean monorepo, not monopackage. Cabal (and Stack too but I don't know the details) let you maintain several cabal packages in a single project repository, which you can then individually submit to Hackage. |
| 2025-01-16 01:03:25 +0100 | <haskellbridge> | <sm> Guest71: it may be a good move, but you will have to think about it from time to time, even with automation, if you care about packaging (one or more of your packages will break with X ghc/dep version / on Y platform, disrupting your/packagers' scripts... etc.) |
| 2025-01-16 01:03:16 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 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 |