Feedback wanted: workspace-style multi-flake dev tool

Help
1

Hi all,

I’ve been mulling over a workflow idea and would like feedback before building anything.

One thing I want to bake in from the start: a workspace shouldn’t be a permanent structure. It should be cheap to spin up an ad-hoc grouping of loosely related repos for a session, and equally cheap to throw away. Less “monorepo with commitment,” more “temporary scaffolding around whatever I happen to be touching today.”

The pattern

When using flake-parts, I split each repo into two files:

  • flake.nix — thin entry point, basically mkFlake (import ./parts.nix)
  • parts.nix — the actual flake-parts module (packages, devShells, etc.)

This is close to the flakeModules.default convention many flake-parts libraries already use.

The workspace idea

Say I’m working on three related repos — foo, bar, baz — each with its own flake.nix + parts.nix. I want to develop all three together as a single workspace, where local changes in bar are immediately visible to foo. Cargo/pnpm-style workspace, but for flakes — and, per the framing above, formed on demand rather than declared up front.

I’m picturing a small CLI that:

  1. Scans sibling directories for flake.lock files,
  2. Generates a root flake.lock that unions inputs from each repo and imports their parts.nix modules,
  3. Wires up local path overrides so cross-repo changes are live.

Why not existing tools?

Most existing options (devenv, std, blueprint, nixos-unified, Omnix, etc.) feel monorepo-shaped to me — they help structure a single repo, not compose several. What I’m looking for is an easy way to do polyrepo composition.

Open questions

  1. Has anyone tried this and hit walls I’m not seeing?
  2. My current plan for input/option conflicts (different nixpkgs pins, conflicting follows, etc.) is to make parts.nix workspace-aware by construction — i.e., define options so the module system merges them cleanly, rather than reconciling clashes after the fact. However, I’m not sure we can reuse existing flake-parts modules with this approach.
  3. Any prior art I’m missing?

Thanks for any thoughts!

1 Like