| 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 |
| 2025-01-16 01:00:51 +0100 | jcarpenter2 | (~lol@2603:3016:1e01:b9c0:794b:ce9f:2a3d:41ae) (Ping timeout: 252 seconds) |
| 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:03:16 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 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: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:49 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-01-16 01:03:50 +0100 | ljdarj1 | ljdarj |
| 2025-01-16 01:04:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:05:24 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 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:06:09 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f02edd754543fe6660f.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 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:08:56 +0100 | <Guest71> | jackdk: It could work as a monorepo too. In fact, it used to be a monorepo and was later broken up (even the namespacing was mostly kept). Do you believe a monorepo with micropackaging would be better? |
| 2025-01-16 01:09:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-16 01:11:18 +0100 | <jackdk> | I consolidated work's split repositories into a monorepo, which has since grown to ~150kLoC. It was a large improvement because maintenance often topologically sorting the repositories in your head and working from the leaves up, and if something broke you often had to go back to the leaves and start again. |
| 2025-01-16 01:11:32 +0100 | <jackdk> | The monorepo has been a massive QoL improvement. But the depgraph is relatively deep; if your project's depgraph is wide and shallow you might not hit this problem. Why did you split it up? |
| 2025-01-16 01:12:49 +0100 | <jackdk> | Also, perhaps the term "split packaging" is more accurate than "micropackaging"? The latter makes me think of `left-pad` and single-function libraries. |
| 2025-01-16 01:15:15 +0100 | <jackdk> | The way I see it, you have several options: 1a. monorepo, monopackage; 1b. monorepo, single package with sublibraries; 1c. monorepo, split packages; 2a. multi-repo, automated consolidation to single package; 2b. multi-repo, automated consolidation to package-with-sublibraries; 3. multi-repo, individual packages |