This is fair, but I’m afraid I also think the documentation for snowfall, while nice in places, is pretty mid in places. I think there’s things that could be done to reduce that learning curve a fair amount.
A template and a guide would be an awesome start
Without a doubt. I would consider Snowfall Lib’s documentation as one of the lower bars to clear. The quickstarts are barebones, there are no guides, examples for most things don’t really exist, and the most useful part of it is the reference page which is just everything all at once. I would be very happy if we did better than that and, hopefully, we will with more people working on it!
Yeah, I’ve checked out snowfall a ton, but could never get a derivation working because the docs were really sparse. I’d like to write some but I’d need some help understanding it first lmao
Our configuration is nice, but also not a particularly common use-case. I think the lessons we’ve learned will be more useful for writing something simple than what we have actually written
Still, no problems with people pulling from it… probably we should relicense under whatever we’re putting templates under
Sure, but this is our license. We licensed it under AGPL (our default). We should talk to Pinea about changing that to MIT if we want to let Aux pull from it.
pr’ed a small C template based on the rust one
pr is ready, if anyone willing to review 
I can take a look to confirm the nix stuff but someone more well versed in C should also take a look
I’m pretty aware of nix stuff, so i can take a look.
Hopefully, it’s good enough 
Is there a need to split the flake into multiple files?
It seems to only add complexity to the template to me
It allows it to have old nix compatibility. that’s the main thing for me. Also prevents redeclaring the package a few times.
Shouldn’t be default.nix file be eelco’s flake-compat?
That’s only for channels support.
What does this do?
overlays.default = final: prev: {
hello = final.callPackage ./default.nix {};
};
this allows the user to consume the overlay and it will be added the nixpkgs list. so i could use enviroment.systemPackages = [ pkgs.hello ]; instead.
The overlay replaces it, which is the point, it is usually used to replace older versions of a package with a newer one.