flake-parts
nix-snapshotter
Our great sponsors
flake-parts | nix-snapshotter | |
---|---|---|
5 | 3 | |
586 | 471 | |
9.0% | 4.7% | |
7.5 | 8.2 | |
14 days ago | about 1 month ago | |
Nix | Go | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
flake-parts
-
Nix is a better Docker image builder than Docker's image builder
There are attempts like
https://flake.parts/
or
https://github.com/nix-community/flakelight
Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.
-
Nix noob question
You can also just install flakes doing nix profile install . I wrote a tool to make it a bit easier, npt but it's completely optional. Once you install the packages with nix profile. Then in your repos you can use a flake with a devShell and run nix develop. Check https://flake.parts to write your flakes.
-
I'm getting on the hype train. What do you recommend to beginner?
Definitely use flakes from the get-go. It's much more sane. Nix's documentation can be unorganized, but read through it when you can. Modules and other projects tend to have their own documentation as well, like Home Manager and flake-parts
-
Why you don't need flake-utils
That's not a typo, there OP is referring to https://github.com/hercules-ci/flake-parts
nix-snapshotter
-
Tvix – A New Implementation of Nix
Not super recent, but nix-snapshotter is one that I'd call awesome(but I'm also a k8s fanboi): https://github.com/pdtpartners/nix-snapshotter
https://news.ycombinator.com/item?id=37407758
-
The What, Why and How of Containers
Excellent info! I started head-deving a project similar to nix-snapshotter[0] and I was thinking "ok, I can probably just build CRI impl that builds a rootfs dir with nix and just shell out to bubblewrap to make a "container".
But once I went through that mental exercise I started reading code in containerd and cri-o. Wow, these are _not_ simple projects; containerd itself having a full GRPC-based service registry for driving dynamic logic via config.
One thing I was pretty disappointed about is how deeply ingrained OSI images are in the whole ecosystem. While you can replace almost all functional parts of runtime, but not really the concept of images. I think images are a poor solution to the problem they solve, and a big downside of this is a bunch of complexity in the runtimes trying to work around how images work (like remote snapshotters).
[0] https://github.com/pdtpartners/nix-snapshotter
-
Nix is a better Docker image builder than Docker's image builder
Does anyone here have any experience using https://github.com/pdtpartners/nix-snapshotter ?
I build a lot of Docker images using Nix, and while yes it’s generally more pleasant than using Dockerfiles, the 128 layer limit is really annoying and easy to hit when you start building images with Nix. The workaround of grouping store paths makes poor use of storage and bandwidth.
What are some alternatives?
nix-beam-flakes - Nix-based BEAM toolchain management
dev-templates - Dev environments for numerous languages based on Nix flakes [maintainer=@lucperkins]
treefmt-nix - treefmt nix configuration
nvfetcher - Generate nix sources expr for the latest version of packages
haumea - Filesystem-based module system for Nix [maintainer=@figsoda]
nixt - Simple unit-testing for Nix [maintainer=@Lord-Valen]
Nix-Config - My Nix Config
npt - Nix Package Tool. A (humble) successor to linux's apt, which makes life easier when using nix as a package manager.
dotfiles - Personal configuration files for my PC