I think we should separate this into two separate examples, one with just inherit pulling defined values, and then another with pulling values from an attr set.

Also, nix repl might be better here, so we don't have to leverage a let block

nix-repl> name = "foo"

nix-repl> version = "0.1.0"

nix-repl> :p { inherit name version; }
{ name = "foo"; version = "0.1.0"; }

I was deliberately attempting to be concise, although I'm not super against splitting it in two examples either, however in this case isn't the let block part of the demonstration since it's one of two places where an inherit can ocur?

Also, in regards to repl style blocks, I was attempting to follow the Rust way of writing valid code blocks that could be pulled out and evaluated independantly to a boolean. It'd be great if we could somehow find a way to automate this to ensure our examples stay valid.

However, maybe this isn't as important as with Rust since Nix doesn't really change that much?

I think there's a lot going on in the blocks, let ... in block, recursive definition of set, then inheriting the value, and then a comparison which isn't demonstrated.

The rust-lang book has a leg up in that you can just execute code. Until then we will need to be more acommodating.

The other thing is that it's not apparent how to run the code, nix eval -f example.nix would probably be right, but that's not apparent to the user.

I've been doing

$ cat <file>

$ <nix command> <file>

For now, but it would be nice to move away from this. Just not sure what would be best.

Perhaps what is needed is to develop a mdbook plugin to actually evaluate the code in browser and CI, similar to Rust. This is definitely outside of the scope of this PR though.

I went ahead and split this into two (hopefully simpler) examples.

If we ran this in the repl, we could do something like:

nix-repl> { inherit name; } == { name = "foo"; }
true

feel like we could extend this further

this would also introduce the "deeply nested" syntax