nix
napalm
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.
nix
-
NixOS 21.05 Released
I was able to make the switch over cold turkey after ~9 years of ArchLinux.
By sheer happenstance, I blogged earlier this week about one particular killer feature that doesn't get enough air time: https://news.ycombinator.com/item?id=27344677
My not-flake-yet configuration can be found at https://github.com/rraval/nix
-
Nix solves the package manager ejection problem
> How do NixOS users typically manage software that is not a Nix package
By writing a Nix package for it (I don't mean for this to sound flippant, tone is a bit hard to convey over text).
For example I have this alpha quality rust binary that I'm developing but I also want a stable version installed at the OS level. I write a Nix package and simply compose it into my overall NixOS configuration alongside the more official Nixpkgs: https://github.com/rraval/nix/blob/master/git-nomad.nix
> like a source code tarball where you would traditionally run configure && make && make install?
Nix has a bunch of defaults that make a conventional package like this straightforward.
Here's a package for a vanilla C binary + library that does the `autoreconf && ./configure && make && make install` dance: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/secu...
It's almost a little misleading because the actual steps are largely inherited from the defaults, you can read more about `stdenv.mkDerivation` here: https://nixos.org/guides/nix-pills/fundamentals-of-stdenv.ht...
napalm
-
niv, naersk, napalm: moving on
I created https://github.com/nmattia/napalm/issues/34 and https://github.com/nmattia/naersk/issues/183 to move them to nix-community
-
NixOS 21.05 Released
Sure. NPM is the easy case because the package-lock.json file can easily be read by Nix and contains hashes for all of the packages. This means that simply be importing the file into Nix you can have a reproducible build. No Nix-specific maintenance required.
In the linked case I use this library to manage that https://github.com/nmattia/napalm (in that example I use master but for production I would pin a version). It simply parses the package-lock.json, downloads the packages and uses npm to build the node_modules folder. It also provides some convenient functions for building packages with "bin" files or just linking node_modules inside a build.
Note that this is more for project development. It doesn't use the "system" packages (intentionally) for Node, it fetches whatever versions you have specified from NPM. Nix will only provide the "native" stuff like Node and NPM themselves and any native libraries.
What are some alternatives?
Home Manager using Nix - Manage a user environment using Nix [maintainer=@rycee]
nixGL - A wrapper tool for nix OpenGL application [maintainer=@guibou]
NixOS-docker - DEPRECATED! Dockerfiles to package Nix in a minimal docker container
naersk - Build Rust projects in Nix - no configuration, no code generation, no IFD, sandbox friendly.
nixos-shell - Spawns lightweight nixos vms in a shell
runix
flake-utils-plus - Use Nix flakes without any fluff.
nixos-generators - Collection of image builders [maintainer=@Lassulus]
nix-processmgmt - Experimental Nix-based process management framework
nix-bundle - Bundle Nix derivations to run anywhere!
nix-direnv - A fast, persistent use_nix/use_flake implementation for direnv [maintainer=@Mic92 / @bbenne10]