4 ms·

Perhaps a bit off topic, but I've been playing around with NixOS lately, and I don't understand what the advantages of using flakes are, or really what problem

by aquova 3y ago

Perhaps a bit off topic, but I've been playing around with NixOS lately, and I don't understand what the advantages of using flakes are, or really what problem they solve. Granted, my interest in Nix is simply because I think it's cool to have the OS be configurable from a file, and I'm personally less interested in some of the reproducibility features. I've tried reading up[0] on some of the advantages of using them, but my eyes start to glaze over pretty quickly. [0] https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes

VTimofeenko 3y ago
In a traditional nixos install you have two moving parts -- configuration.nix(and whatever modules it imports) and channels. Channels are updated independently which makes it harder to reason about the system at a specific point in time. Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together. That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
- SkyMarshal 3y ago
  > That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted. That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise. One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.
rgoulter 3y ago
A flake.nix file is somewhat comparable to a package.json file in a NodeJS project. Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses. The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix. The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.
jsmith45 3y ago
Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenario is not helpful Vs a flake with its structure allowing a standardized way to express many things. With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.) This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos. -- Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems. Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.

by aquova 3y ago

VTimofeenko 3y ago

In a traditional nixos install you have two moving parts -- configuration.nix(and whatever modules it imports) and channels. Channels are updated independently which makes it harder to reason about the system at a specific point in time. Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together. That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.

SkyMarshal 3y ago
> That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted. That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise. One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.

rgoulter 3y ago

A flake.nix file is somewhat comparable to a package.json file in a NodeJS project. Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses. The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix. The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.

jsmith45 3y ago

Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenario is not helpful Vs a flake with its structure allowing a standardized way to express many things. With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.) This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos. -- Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems. Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.