-
Notifications
You must be signed in to change notification settings - Fork 49
Open
Description
snowfall is a very popular opinionated code organizer built on top of flake utils+ and beloved by NixOS users. For this reason, I can see a number of benefits over std:
- Better futureproofing against changes to flakes which is especially important since flakes are still experimental.
- Easier to define NixOS modules and configurations for integration testing. Even though snowfall is best known for NixOS configurations, I get a lot of mileage for local projects. My usual workflow is to create
./package/service-app/default.nix
, define some unit tests for that package either using the in-built testing functionality of the language or usingrunCommand
, create a corresponding nixosModule test integration withrunNixOSTest
under./checks/
. I could even imagine definingnixosConfigurations
for particularly complicated integration testing and have no problem implementing this with snowfall. On the contrary, I have no idea how I might do the same in std. - Lighter weight. std comes with a lot of baggage, some of which is good (adbrecords!), some of which is bad (lefthook is dragged along when I want to use cachix-maintained pre-commit), and some of which is just plain ugly (generating treefmt.toml files when treefmt has direct integration with nix!)
Overall it has left me with the desire for and smaller, std-style code organization and typing that follows the flake-output schema (maybe with flake-parts' flakeModules included) rather than the monolithic devops framework that exists. Perhaps I have gotten the wrong end of the stick here, but I don't see any benefit, and plenty of drawbacks, over something like snowfall. If you could add a comparison section for snowfall that would be very useful!
sokai
Metadata
Metadata
Assignees
Labels
No labels