Smoothing the flakes learning curve

[raboof]

@jacg

I interpret your suggestion to be that each step should evolve on separate topological branches:

c88412b <- 11ef8c3 <- 4533c95 <- step-1
9d27c50 <- 2612b61 <- 81b4bc9 <- 50b3664 <- step-2
4547fb5 <- 013ddc8 <- step-3
shellspec

with one disconnected sub-DAG for each step’s history.

• My original has multiple Git branches on a single, connected DAG
• Your proposal has multiple disconnected (sub-)DAGs with a Git branch at the HEAD of each.

I was thinking of having merge commits. This gets hard to represent in ascii art though . Anyway let’s not go into this further since if I understand correctly you want to be able to do updates touching multiple steps in a single MR.

@jacg

@raboof

and a script to convert those into separate branches/commits on a repo for consumption by your visitors.

I suspect that in the end the presentation repo’s history will have to be generated by some script, from the contents of a (probably) separate repo in which the whole thing is developed.

That was exactly my thinking. So the ‘master repo’ might have all steps side-by-side on the same commit (for example flake-step1.nix, flake-step1.nix, etc or step1/flake.nix, step2/flake.nix etc). There you can collaborate and update all steps in 1 MR.

@jacg

What worries me here is how to test stuff quickly and interactively in the development repo: the flakes in the development repo should work identically (and have the same external interface including stuff like nix run github:user/repo/branch !) to the ‘official’ ones.

That won’t work, but perhaps that is not such a big problem: if generating the ‘visitor-facing’ representation of the flakes repo is fast then you can just run that script each time you want to test - perhaps even automatically on file changes.