nictool2 to nictool3 dev workflow

[aberoham]

As-is legacy v2 is totally separate, and v3 layers distinct repos on top of published libraries whilst being backwards DB-schema compatible with v2. It would be nice if a single simple'ish entry point existed that booted up v3 optionally alongside v2. The goal would be to help mimic what existing v2 deployments might be surprised by if they attempt a v3 upgrade, and to make it very easy to confirm the v2 upgrade path alongside v3 as v3 evolves.

[aberoham]

I had my Claw come up with this "monorepo" approximation. See https://github.com/burning-bush-dev/nictool-monorepo

What do the real humans think?

Direction OK? Name OK? Cool if I put that repo under the NicTool org?

[msimerson]

I was looking at monorepo and workspaces but I really want to keep the packages independent, especially since dns-RR could likely be reused by others.

I hadn't considered that we could have both a monorepo AND have them separate using submodules. I like the idea and yes, add the repo to the nictool org.

[aberoham]

Ok, https://github.com/NicTool/monorepo is live. I took the liberty of also adding https://github.com/NicTool/research/. Within research/, I should probably also commit the prompts that were used for any generated outputs.

It's slightly annoying how git submodules can't simply track a relative pointer such as "HEAD." Perhaps a GitHub Action could take care of updating the commit references based upon the branch hint within .gitmodules.

I've tested the monorepo locally on a fresh machine and all seems well, as long as I first cherry-pick the PRs around Docker and tests that haven't yet landed: NicTool/server#3 NicTool/NicTool#342