Newest at the top
| 2025-01-16 02:03:02 +0100 | <Guest71> | jackdk: From skimming the summary that looks exactly like the kind of project I'm developing |
| 2025-01-16 02:02:53 +0100 | <haskellbridge> | <sm> if the different packages have heterogenous dependencies, such that some of them may be hard to build on certain platforms / with certain GHC versions, that could be a reason to segment. If the deps are the same for all of them, and the only issue is downloading unused code.. that's not a big cost |
| 2025-01-16 02:01:20 +0100 | <jackdk> | OTOH, I consider it a good thing that all the different regex engines in the `regex-*` universe are in different packages, because you usually just pick one (either TDFA or PCRE) and stick with it. I wouldn't use `regex-base` as a guide for how to design an interface usable by multiple implementations, though. My head spins every time I look at it. |
| 2025-01-16 02:00:37 +0100 | <Guest71> | The interface is actually remarkably boring, and by far the least important part. It only exists because I want my users to be able to swap implementations transparently and benchmark the differences for their workloads easily to make a more informed decision. |
| 2025-01-16 02:00:35 +0100 | <haskellbridge> | <sm> +1 |
| 2025-01-16 01:59:41 +0100 | <jackdk> | I'm reminded of https://hackage.haskell.org/package/ad which has a bunch of different automatic differentiation methods in a single library. If the scope of each operation is relatively small, a similar approach may serve you well. It can be annoying to ask your users to go back to their cabal file and re-jig their build just to experiment with another implementation of the same method. |
| 2025-01-16 01:57:33 +0100 | <haskellbridge> | <sm> good idea! validate your repo/package organisation a little before committing to hackage uploads |
| 2025-01-16 01:57:00 +0100 | <Guest71> | As an example: there are many ways to compute a logarithmic expression. So, you have different sub-projects that implement the different ways. Depending on your algorithm or problem as a user of the library, you may prefer one or the other. Maybe you have different use-cases, and you want to use more than one. |
| 2025-01-16 01:57:00 +0100 | <Guest71> | The interface is a collection of numeric operations and the implementations are well... different ways to implement each of them. |
| 2025-01-16 01:55:31 +0100 | <jackdk> | At this point I'm not sure I know what questions to ask. I will point out that you can soft-launch a package by uploading it to a public repo and working from there. Both Cabal and Stack let you pull in code from git repos, and then hopefully you can attract more users and find out what splits they're looking for |
| 2025-01-16 01:55:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-16 01:54:48 +0100 | <ColinRobinson> | 'unit of compilation' is the clear but you generally only see that in specs |
| 2025-01-16 01:52:42 +0100 | <jackdk> | I was planning on getting an idea of the problem you are trying to solve, because my head is in the HTTP API space by default. I don't know much about numeric code and how people expect it to be organised. |
| 2025-01-16 01:52:22 +0100 | <Guest71> | Or rather, just tell me what information you would like about the project. |
| 2025-01-16 01:51:33 +0100 | <Guest71> | jackdk: were you planning to look at the repo? |
| 2025-01-16 01:50:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:50:09 +0100 | JuanDaugherty | ColinRobinson |
| 2025-01-16 01:50:04 +0100 | <Guest71> | JuanDaugherty: sorry, I'm not sure what you meant by that (re: namespaces being just namespaces) |
| 2025-01-16 01:49:11 +0100 | <Guest71> | It's a numeric library |
| 2025-01-16 01:49:06 +0100 | <Guest71> | It basically combines a bunch of numeric interfaces and add some other stuff on top |
| 2025-01-16 01:48:40 +0100 | <Guest71> | I'm currently in the process of trying to publish it, hence this conversation :) |
| 2025-01-16 01:48:15 +0100 | <Guest71> | Oh, sorry, it isn't public as of right now. |
| 2025-01-16 01:47:44 +0100 | <JuanDaugherty> | can a namespace just be a namespace? names r powerful, their rectification is a whole deal |
| 2025-01-16 01:47:38 +0100 | <jackdk> | Ideally a link to a high-level API page. So far I have found a page on cloud-based aged care software and a PDF report from a consultancy about Smart Meters for the Australian Energy Market Commission. Please, help us help you. |
| 2025-01-16 01:47:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8310:6e2:3d63:5127) (Ping timeout: 248 seconds) |
| 2025-01-16 01:46:13 +0100 | <Guest71> | Though I imagine you were hoping for something descriptive |
| 2025-01-16 01:45:51 +0100 | <Guest71> | jackdk: it's called Nera |
| 2025-01-16 01:45:08 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 01:44:49 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-16 01:43:45 +0100 | <jackdk> | At least its name, I mean. |
| 2025-01-16 01:43:37 +0100 | <jackdk> | I think knowing the specific interface would be extremely helpful, if you can provide it. |
| 2025-01-16 01:43:21 +0100 | <JuanDaugherty> | "module" is more of a construct and often enough contentious, eg. in prolog |
| 2025-01-16 01:42:59 +0100 | <Guest71> | The project originally had a form of Foo.Iface, Foo.Bar.Baz1, Foo.Bar.Baz2, Foo.Bar.Baz3... all the BazN modules implement the Foo.Iface |
| 2025-01-16 01:41:57 +0100 | <Guest71> | I can tell more about the project, it's not a secret. I just don't want to overwhelm you with noise. |
| 2025-01-16 01:41:41 +0100 | <JuanDaugherty> | cause in that time computers were called ibm machines so their usages became industry norms, even tho there was actually much greater arch diversity |
| 2025-01-16 01:41:15 +0100 | <geekosaur> | there is no real concept of related-ness; a different package could also use the Foo.Bar "namespace" |
| 2025-01-16 01:40:58 +0100 | <jackdk> | Without knowing what the mysterious API is, it sounds like the bindings are more loosely coupled than Amazonka's. This makes me lean toward either option 1c (monorepo with split packages) or 3 (split repos with individual release infrastructure) |
| 2025-01-16 01:40:57 +0100 | <geekosaur> | modules |
| 2025-01-16 01:40:51 +0100 | <Guest71> | The modules called Foo.Bar.* |
| 2025-01-16 01:40:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-16 01:40:44 +0100 | <Guest71> | What do I call everythin under Foo/Bar? |
| 2025-01-16 01:40:40 +0100 | <haskellbridge> | <sm> a project can consist of one or more repos which may store one or more packages |
| 2025-01-16 01:40:36 +0100 | <Guest71> | As in I have lib/Foo/Bar/Baz.hs |
| 2025-01-16 01:40:33 +0100 | <geekosaur> | if you mean module namespaces, they're pretty fake |
| 2025-01-16 01:40:19 +0100 | <geekosaur> | which kind of namespace? |
| 2025-01-16 01:40:16 +0100 | <JuanDaugherty> | yes them |
| 2025-01-16 01:40:05 +0100 | <Guest71> | Okay, point taken. What's the best way to call everything under a namespace? |
| 2025-01-16 01:40:04 +0100 | sprotte24 | (~sprotte24@p200300d16f35c200f4f310a9fb58ced0.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-01-16 01:40:03 +0100 | <geekosaur> | (for which we have IBM to blame, IIRC) |
| 2025-01-16 01:39:56 +0100 | <haskellbridge> | <sm> +1 to jackdk. "package" is the right term for units of hackage/cabal/stack-stuff |