I’ve only written the first chapter so far, and want to extend it in the future to show how to how to modularise things, re-use more code and write sophisticated multi-machine interactions.
Is it? If you can show me a shell.nix based example that can do all the things my wrapper can currently do, I’ll probably switch to it.
dropdown box that switches different sections to use vagrant,aws,etc
Not sure how you mean, like in the tutorial? I don’t think Github’s Markdown can do dropdown boxes. Also if I add those, I’d also have to keep them updated and ensure they work, so I’m not super sure about it.
best practices for storing/sharing the nixops state
Yes, that’d be a good addition, but I’ll probably focus on that after making some more sophisticated examples.
My preferred solution is to just use a bastion machine that all team members use. If high availability is needed against failure of the bastion machine, I’d put the nixops sqlite file onto a highly available POSIX network file system like CephFS.
Here is an example of a shell.nix that pins two nixpkgs releases, it doesn’t pin any tool to the unstable version but doing that is just a fetchTarball away
Also, it’s much better for me to enter the custom environment at the beginning, using the commands, and then exit it. Probably it’s more efficient too…