| 29 Jan 2026 |
 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 |
| llakala | anyways in this approach, this file is our only source of truth | 15:51:44 |
| llakala | if we have some extra info in lock.nixpkgs, we could probably prevent desync by detecting when the lock and the source disagree | 15:52:43 |
| Coca | the issue still pretty much remains, in nix there is no way for us to edit files to update the locks, the user would see the locks are mismatching but they'd still need to do something extra | 15:52:44 |
| llakala | In reply to @coca162:matrix.org
the issue still pretty much remains, in nix there is no way for us to edit files to update the locks, the user would see the locks are mismatching but they'd still need to do something extra oh yeah wait of course | 15:53:18 |
| llakala | I forgot we couldn't edit files in nix | 15:53:23 |
| llakala | and I was imagining we could just update the lockfile for the user | 15:53:35 |
| llakala | i mean we could error out if there's a desync | 15:53:47 |
| llakala | the alternative would be an in-repo minimal executable | 15:54:52 |
| llakala | but I guess you couldn't call that from within a rebuild | 15:55:47 |
| llakala | so you'd have to use that for all your nix commands, which seems suboptimal | 15:55:58 |
