Exactly this. One of the first things I tell people struggling with nix is that nix is simple and almost all of the complexity lives in nixpkgs. Knowing where to look for help (is this a nix, flakes, NixOS, or nixpkgs thing?) is one of the hardest problems for beginners.
Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.
My personal experience (model y lr) is 4 hour trips are the sweet spot and anything over 6 hours becomes a drag. I can reliably go over 200 miles @ 80mph without charging but after the first charge you have to stop every 100 miles or less. When we do long cross country trips (8+ hours per day) we take the gas car.
I just got back from a road trip in France and the UK and it's funny how much of the reddit-tier discourse is correct yet simultaneously so wrong. There are plenty of rural towns where everyone owns cars. There are highways, strip malls, large shopping centers with massive parking lots, and populated areas with bus service at best. The difference is the scale and the US lands embarrassingly far on one side of it. Even in the smallest rural towns in France we visited, we could hop on regional rail to the nearest large metro area.
If you're doing trunk based development, with continuous integration, then you're approximately always on a public branch, and rebasing is not very useful.
Thanks Graham! Glad to see some attempts at improving the dx of sharing expressions with flakes instead of just derivations. I've seen libraries and tools handle this in a ton of different ways. Do you think there will ever be a standardization of the 'lib' output?
I hope there will be, but I'm not really sure. I think the future of Nix is in smaller, focused flakes being shared and exchanged. People dunk on projects like Rust and Node for having infinity dependencies, but it is that way because those ecosystems have rich library ecosystems that are worth using. I see the same thing happening in Nix.
Regularization of more Flake outputs into schemas sounds compelling. E.g. thanks to this great work on flake schemas, do the definitions of outputs related to NixOS modules, NixOS configs, and nixpkgs overlays even need to be pre-baked into Nix?
In terms of this decomposition effort, one additional thing that would be really nice to see would be turning flake URL schemes & updaters extensible. One could imagine some kind of a dictionary that maps from schemes to derivations that contain the code needed to get the primitive URL for the "latest" version of the flake when an update is called for.
I totally agree. This is one of the reasons we made FlakeHub, to make a better update mechanism that was flexible and supported things that aren't just github as sources. I think that'll happen, it'll just take a bit of time, and likely experimenting outside of nix before patches land upstream.
My path was vm -> containers -> nix. With nix flakes and the direnv extension in vscode you can get a clean per-project dev environment with zero docker overhead and without dev tools cluttering up your global environment and causing issues.
I like them for defining a small number of env vars for my app that only get injected at run time. I don't like them when other random tools that aren't my app use them. Docker's insistence on automatically using the .env in your home directory is absurd.
Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.