| 29 Jan 2026 |
 lillecarl | nix eval --file . attr
nix build --file . attr
nix repl --file . attr
I used to use flakes, I use these commands just about all the time. I never "learned" the "old" ones | 15:03:21 |
 neobrain | I was also wondering about this (when you said something to the effect of "flakes have won" the other day) - is there data on this or is it anecdotal? | 15:03:25 |
| neobrain | * I was also wondering about this (when you said something to the effect of "flakes have won" the other day) - is there data on how many people use flakes or is it anecdotal? | 15:03:50 |
| neobrain | * I was also wondering about this (when you said something to the effect of "flakes have won" the other day) - is there data on how many people use flakes (vs not) or is it anecdotal? | 15:03:56 |
 delroth | detsys has published data about flake.nix presence in new github repos which shows overwhelming usage | 15:04:13 |
| delroth | a lot of mental gymnastics has been done around this because detsys is a biased actor and their methodology isn't perfect | 15:04:41 |
| lillecarl | I don't doubt it's true though, I'm happy any time i see someone who didn't buy into the flake hypetrain. | 15:06:25 |
| neobrain | hmm. it's slightly more awkward than nix eval .#attr, but I guess still better than nix-env -lettersoup attr | 15:06:28 |
| delroth | https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959?u=delroth from 1.5 years ago (and there isn't a big reason to think the trend would have changed) | 15:06:42 |
 Coca | (did they really have to use this color scheme? I can barely see flakes-and-legacy here) | 15:08:26 |
| lillecarl | "legacy" is a good name too 🤣 neobrain you can use flake-compatish to get the benefits of both flakes and non-flakes with minimal effort 😄 | 15:10:41 |
 aloisw | In reply to @delroth:delroth.net
not necessarily channels (which are pretty terrible), my nixos machines are configured to have the nixpkgs they're built from symlinked at /etc/nixpkgs and a nix.nixPath = [ "nixpkgs=/etc/nixpkgs" ]; Something about the name "channel" meaning too many different things … | 15:12:54 |
| neobrain | Pragmatically that's nice, though I appreciate having a "standard way" of doing stuff in nix, which flakes seem to be the closest candidate for. Much easier to implement external tooling if everyone isn't using their own bespoke little setup | 15:17:00 |
| lillecarl | That's the thing with flake-compatish. You can always use flakes, but when you don't want the downsides of flakes you work around them. It can be seen as an "optional addon" rather than a replacement. Being able to quickly override inputs to local paths (or other flakerefs) without molesting the lockfile is pretty convenient, especially if you're a flake user who against all odds decide to contribute to nixpkgs 😄 | 15:20:26 |
| lillecarl | * That's the thing with flake-compatish. You can always use flakes, but when you don't want the downsides of flakes you work around them. It can be seen as an "optional addon" rather than a replacement. Being able to quickly override inputs to local paths (including self for monorepos) (or other flakerefs) without molesting the lockfile is pretty convenient, especially if you're a flake user who against all odds decide to contribute to nixpkgs 😄 | 15:22:30 |
| neobrain | ah yeah I see, makes sense | 15:24:27 |
 llakala | In reply to @coca162:matrix.org
Would it be fine to have to "sync" any edits to the source of truth as a separate action from evaluating the sources? The nice thing with flakes is that they can reflect the changes in flakes.nix without you needing to explicitly tell it to do so as the commands are built to handle it, and I'm not sure if not having that ability would make this worth it. wdym by this | 15:42:43 |
| llakala | not fully grasping what you're referring to | 15:42:59 |
| Coca | If I edit a file, the lockfile will not be updated to reflect the changes I have done to the source of truth | 15:43:42 |
| llakala | ah yeah I see | 15:43:52 |
| llakala | yeah I would like autosync | 15:44:28 |
| llakala | i mean I think it would be possible to do it with only nix mechanisms | 15:44:43 |
| llakala | could you hash the npins.nix and see if the contents differ? | 15:45:09 |
| Coca | https://discourse.nixos.org/t/nixtamal-fulfilling-pure-input-pinning-for-nix/74745 funnily I just saw this, so I'm curious how they handle it, unfortunately I cannot comment however due to my trust level so I will just poke around at it | 15:45:15 |
| Coca | * https://discourse.nixos.org/t/nixtamal-fulfilling-pure-input-pinning-for-nix/74745 funnily I just saw this, so I'm curious how they handle it, though unfortunately I cannot comment due to my trust level so I will just poke around at it | 15:45:36 |
| llakala | i didn't look into nixtimal too much, it only uses derivation fetchers which I find a little silly | 15:46:01 |
| llakala | if you wanted to be really crazy, you could have a single npins.nix file with two attrsets within it | 15:47:16 |
| llakala | ```nix
{
sources.nixpkgs = {
type = "github";
owner = "nixos";
repo = "nixpkgs";
branch = "nixos-unstable";
};
lock.nixpkgs = {
ref = "some-git-ref-here";
url = "https://github.com/nixos/nixpkgs/some-git-ref-here.tar.gz";
hash = "sha256-blahblahblah";
};
}
``` | 15:50:32 |
| llakala | * ```
{
sources.nixpkgs = {
type = "github";
owner = "nixos";
repo = "nixpkgs";
branch = "nixos-unstable";
};
lock.nixpkgs = {
ref = "some-git-ref-here";
url = "https://github.com/nixos/nixpkgs/some-git-ref-here.tar.gz";
hash = "sha256-blahblahblah";
};
}
``` | 15:50:40 |
| llakala | god i hate matrix | 15:50:49 |
