It's pretty important to decide how workspaces and catalogs interact. Too many options will be confusing; too few options may force users into weird spamming of workspaces which would also eventually end up confusing. And changing it after first conception will probably create painful migration issues.

Some thoughts:

• You can't refer to different catalogs in formula inputs. Which strongly argues there's no sense in having more than one catalog per workspace.
• The major 🔑 to making catalogs work well is pollination.
  • I tend to think we're mostly going to have things pollinate "up", and then implicitly get pulled "down" when used. The "up" motion is explicit.
    • Basically implies we're going to have a parent workspace with a global catalog.
• A project that's in its own git repo needs to have its own workspace. That workspace needs to have a single catalog, vendored, which contains a copy of every lineage that's relevant.
  • The lineages may be sliced to only include the relevant versions, too, I suppose.
• A uniform global catalog doesn't really sound right. I don't know how that's gonna scale, humanly.
• I sometimes want to draft a whole swatch of potential releases of things, which may be released into multiple lineages. Unclear how easy that's going to be. We considered a 'saga' concept, which was basically named alternative catalogs (or at least, named alternative candidates overlays on top of the main catalog) for this, but didn't really get enough info on if this was a useful idea or not.
• A major thing I'm concerned about is having more than one workspace on your computer, and getting the same project in each workspace, and getting conflicting catalog evolutions in each one.
  • Maybe workspaces should have an opt-in sort of situation with what lineages are expected to be appendable in this workspace? Does that sound useful? Would this make pollination flows clearer?
  • Proactively checking that parent workspaces haven't diverged in any way is probably a good idea.
  • Nothing can really help with network scale desyncs. So that creates an upper bound about how much this is even worth worrying about. It's kinda like two people creating conflicting tags in git. It's gonna happen.
    • It's slightly worse than creating conflicting tags in git because releases in a lineage are ordered, whereas git tags are not, which means any uncoordinated change is a conflict producer. And we're intending to forward-lock things pretty heavily.
  • Are we going to want some lineages to explicitly not be propagated at all up to any parent workspace catalogs? Yeah, probably: it's called your company's project directory.
    • Not entirely likely this'll happen recursively (though no reason to forbid it either).
    • Allowlist modes? Denylist modes? Both? Whatever. A detail for later.
• Stories about soft-forking and patch overlay quilting might interact with this.
  • ... but those are generally inherently complicated and maybe shouldn't be worried about too much.
  • I think it's not crazy to say "yeah, you actually make a new lineage for that", as long as we make it reasonably easy to invoke a command on a range of your projects that will take all the formulas it encounters and bounce them over to that 'fork' lineage.
• Maybe the key concept is: most workspaces have a single catalog, but you can make one have a composition of overlayed catalogs too.
  • The rootmost workspace which contains the global public catalogs is probably going to use the complicated mode.
  • This doesn't really ask how polination "up" into such a workspace should work.
    • Prompt the first time? You can just flif through each catalog to find matching lineage names each subsequent time. Not super hard.
    • Maybe it doesn't even really matter. Really large global catalogs are probably going to have a growth pathway that does not move through your localhost... it's more likely to involve a submission queue online somewhere, which eventually loops back to being pullable.
      • This is okay and not overly centralizing for our tastes because you can emulate that loop offline.
      • If this takes more complicated commands to work out, that's fine, because it's probably not the usual developer's flow, more something being used on these daemonified release cycle control systems.

Okay, so. A .warpforge/catalog directory by default, and optionally also a .warpforge/catalogs/{name} (mostly for your root workspace) seems about right. And nothing ever writes to the named ones by default; that requires very explicit action. And pollinating things down should rarely if ever require resolving a naming collision, by policy, so we're done. Great.

Let's work through some edge cases:

• What do when there is a naming collision, in the pulling updates from a parent direction?
  • Inapplicable if it's pulling from a unitary catalog.
  • Only applicable if you've got the multiple named catalogs.
    • So: maybe if you've got such a thing, it forces you to resolve it in that workspace?
      • Idk about this. Seems like an option though. I wouldn't often want different opinions about this in projects anywhere near each other; certainly not in a group (distro; company; etc) that's actually working together.
• What do when there is a naming collision, in the publishing updates direction?
  • No such problem. You don't publish things from a workspace; you only ever pull them into a workspace. So if there's any resolution to do, it's always clear where the responsibility lies.
  • Or if you do want this to happen more automatically in your local workspace: the config goes in the parent one. So if there's any resolution instructions, they don't slip down and become decontextualized in the leaf repo (which is good — that kind of decontextualized reference is what we're worried about avoiding here).
• How do candidates propagate?
  • Okay, I'm still not entirely sure.
  • Hypothesis: it's fine to flag an entire workspace as auto-accepting candidates.
    • Probably does the right thing.
    • Probably don't want to do this on your home/root workspace. Our tutorials should suggest making an intermediate workspace, at least. But whatever, it probably even works fine.

About workspace dir discovery:

• Okay, the parentward walk — mostly, duh.
  • (This is also better than last round of timeless stack, btw — it's always a dir, just that one thing, not this complicated mix of files and sometimes-dirs that had Implications.)