Why did Nix adopt Flakes?

I find the default way to work with nixos to be a lot easier to use compared to flakes. I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. I don't think that is a positive.

This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.

Depends on the person. I work in a company that uses Nix for everything one could possibly imagine, and I've found there are a few types of people:

1. The purist: Is on an actual crusade to promote Nix and stomp out any competition, because, "reproducible."

2. The enthusiast: Likes using Nix to speed up development but recognizes it has a ton of shortcomings, among others being not friendly to beginners, and tends to avoid using it in production critical stuff.

3. The ex-Nix: matches the enthusiasm of the purist in stomping out Nix wherever possible and actively promoting its demise.

I'm personally in the second category. I use Nixos for my main development machine and really like devshells. Beyond that, I try to avoid it as much as possible for production.

> It's a package spec, just like debian/* and rpm/*.spec.

No. It's not. The interface that Nixpkgs' callPackage expects to find in default.nix within the Nixpkgs source tree is (kinda) like an RPM spec or Debian control file and friends, but that's not what flakes are.

Flakes is mostly about providing mechanisms for distributing and referring to code written in the Nix language, and in that way facilitates the maintenance of 'out-of-tree' (read: not in Nixpkgs) Nix packages. But flakes can also be (and are) used to ship Nixlang libraries, end user configurations, IaC for clusters or fleets of servers, overlays of packages to be composed with an end user's copy of Nixpkgs, etc.

A flake doesn't have to contain any packages at all. And when it does contain a package, the package is always defined with reference to some other package collection that it pulls its dependencies from (almost always Nixpkgs), and the conventions for describing the build come from there. They're not part of the flakes schema.

> Every distro package ecosystem has the maintainers discuss patches with upstream.

Again, not what flakes are about. The situation the GP is describing is where a Nix package's 'recipe' lives inside the upstream repository* and is maintained there directly by contributors to/maintainers of the upstream project. This is more like a project including a Dockerfile for the convenience of new contributors, or application developers directly publishing their own Flatpak images.

I think it only lazily copies files that are referenced by your nix expression.

I tested this branch, and a flake-based shell launched in 3 seconds inside a large monorepo (vs 30 seconds before). I don't think it is possible to copy this repo in 3 seconds.