Newest at the top
| 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 |
| 2025-01-16 01:39:37 +0100 | <JuanDaugherty> | as opposed to "object module" |
| 2025-01-16 01:39:10 +0100 | <JuanDaugherty> | 'source module" is an ancient idiom for a single file of code text |
| 2025-01-16 01:38:56 +0100 | <Guest71> | sm: I'm expecting not, except for users that happen to have different use-cases that could be better served by different implementations |
| 2025-01-16 01:38:01 +0100 | <haskellbridge> | <sm> will people often want to install all the packages together ? It sounds like not |
| 2025-01-16 01:37:43 +0100 | <jackdk> | That Haskell calls a source file a "module" means I find it confusing to call a unit of project organisation a "submodule", especially when that word had meaning to `git`. For clarity: a cabal "package" has multiple "components" (library, named sublibrary, executable, test suite, etc). One or more "packages" on the filesystem can be collected into a "project", where `cabal.project` lets you apply settings across them. |
| 2025-01-16 01:36:40 +0100 | <Guest71> | sm: issue tracker per package, yes. Docs are basically pure Haddock, so they are split already. I would not release in lockstep. |
| 2025-01-16 01:36:18 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-16 01:35:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:34:24 +0100 | <haskellbridge> | <sm> I think we don't know enough to have (more of :) an opinion |
| 2025-01-16 01:33:32 +0100 | <Guest71> | As for the boundary enforcement, it is true that you may enforce it with cabal. I suppose in my mind that is a sort of "softer" enforcement than splitting repos (boundary enforcement is regulated by a file inside the project repo), so I just reached for the most generic solution. Maybe this was a bad call? |
| 2025-01-16 01:33:31 +0100 | <Guest71> | I was going to say that I wasn't meaning to say git submodules, but Haskell submodules (let's call them subprojects). What I was trying to say is that keeping a monorepo means that a subproject's history is merged together with everything else, which means more work around handing history. |
| 2025-01-16 01:33:25 +0100 | <haskellbridge> | <sm> issue tracker per package ? |
| 2025-01-16 01:32:44 +0100 | <haskellbridge> | <sm> will docs/changelogs be easy to segment by package ? Will you always release all packages in lockstep, or will you allow say a bugfix release to an individual package, complicating release scripts ? etc. |
| 2025-01-16 01:30:34 +0100 | <haskellbridge> | <magic_rb> Ive heard that overly polymorphic code doesnt specialize well, but then id ask why? Because couldnt GHC track what different instantiations of each toplevel binding occur and then based on some metric (plain count, expected machine code size) specialize automatically? I assume something like this happens already, but question is why not well enough where "overly polymorphic" ceases to be a problem |
| 2025-01-16 01:30:02 +0100 | <jackdk> | I just had the strangest case of deja vu |
| 2025-01-16 01:29:58 +0100 | <haskellbridge> | <sm> it's worth thinking about, because you can't erase things uploaded to hackage, or easily rearrange VC history |
| 2025-01-16 01:29:41 +0100 | <Guest71> | Oops, sorry about that. My message got replaced with a copy of the old thing. |
| 2025-01-16 01:29:28 +0100 | <haskellbridge> | <sm> ot |
| 2025-01-16 01:28:54 +0100 | <Guest71> | usage lower. I guess also mapping packages to repos 1-to-1 seemed better design all else being equal, but maybe I am wrong about that one. That's why I wanted input from the community. |
| 2025-01-16 01:28:53 +0100 | <Guest71> | jackdk: Regarding the reason for the split, It was relatively easy to do (each component was contained in a submodule anyway) and figured there was no downside to doing it. On the upside, it enforces API boundaries, keeps your git history relevant (reverting or rebasing across submodules is no fun), and just plain keeps your workstation resource |
| 2025-01-16 01:28:33 +0100 | <haskellbridge> | <sm> long term maintainer and packager capacity, number and type of users are things to consider |
| 2025-01-16 01:26:53 +0100 | <haskellbridge> | <sm> Guest71: I'm just saying that all else being equal, many packages costs more to understand/maintain/package than one package. But all else isn't equal, it'll be an engineering judgement call |
| 2025-01-16 01:24:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 01:22:06 +0100 | <jackdk> | (between the package it contains) |
| 2025-01-16 01:21:48 +0100 | <jackdk> | I don't understand why you brought up git submodules. I agree that they are no fun - I'd have used wholly independent repositories or a single repository. A single cabal project will enforce package boundaries |
| 2025-01-16 01:20:10 +0100 | Guest69 | (~Guest69@2601:642:4103:1b0:a477:319d:e581:377a) (Ping timeout: 240 seconds) |
| 2025-01-16 01:20:05 +0100 | <Guest71> | jackdk: Regarding the reason for the split, It was relatively easy to do (each component was contained in a submodule anyway) and figured there was no downside to doing it. On the upside, it enforces API boundaries, keeps your git history relevant (reverting or rebasing across submodules is no fun), and just plain keeps your workstation resource |
| 2025-01-16 01:20:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:19:41 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |