| 2 Oct 2021 |
|  nf changed their profile picture. | 00:16:52 |
 Las | The issue with that is that GC might remove the Nix in that small available timeframe. | 10:14:17 |
| Las | * The issue with that is that GC might remove the Nix in that small timeframe. | 10:14:24 |
| Las | The best solution is likely installing the new Nix with a higher priority, then uninstalling the old one. | 10:15:04 |
 bew | In reply to @Las:matrix.org
The issue with that is that GC might remove the Nix in that small timeframe. You have automatic gc running? You could always open a nix shell with a nix version, this way you always have one (which cannot be gc'ed)
| 12:06:29 |
| Las | That is another solution. Lots of people have automatic GC running. | 12:07:06 |
 balsoft | I've found a weird issue with Nix not adding a flake source as a runtime dependency. In particular:
environment.etc."nixpkgs".source = pkgs.path;
When pkgs comes from a nixpkgs flake produces a "broken" etc: it has nixpkgs symlink pointing to -source nix store path containing the nixpkgs flake, but this path is not a runtime dependency of etc derivation, e.g. doesn't show up nix-store -qR or nix why-depends. toString-ing the pkgs.path beforehand doesn't fix the issue (as expected, since it gets toString-ed down the line anyways). Doing
environment.etc."nixpkgs".source = pkgs.copyPathToStore pkgs.path;
Fixes the problem, but it's just weird. | 15:04:25 |
 tomberek | Does it help to do string interpolation with pkgs.path as you use it? “${pkgs.path}” ? | 17:11:25 |
| balsoft | In reply to @tomberek:matrix.org
Does it help to do string interpolation with pkgs.path as you use it? “${pkgs.path}” ? Isn't "${pkgs.path}" exactly the same as toString pkgs.path ? | 17:11:47 |
| balsoft | I can try it I guess... | 17:11:53 |
| balsoft | Aha, ok, it seems it is different... | 17:13:15 |
| balsoft | Interesting | 17:13:16 |
| balsoft | Yeah it works fine with "${pkgs.path}" | 17:13:25 |
| tomberek | This comes up sometimes. Interpolation kicks in a “string with context” which gives the dependency tracking the info. | 17:13:32 |
| balsoft | Hm, I thought toString gave a string with context too... | 17:13:46 |
| balsoft | But yeah,
nix-repl> :t toString pkgs.path
a string
nix-repl> :t "${pkgs.path}"
a string with context
| 17:14:10 |
| balsoft | It makes a lot more sense now | 17:14:18 |
| balsoft | But I wonder why I never noticed this before flakes | 17:14:26 |
| tomberek | Well…. It’s a gotcha. And easy to mess up. Not sure what would help fix it in a user-friendly way. | 17:15:08 |
| balsoft | Oh, ok, even more interestingly .source = inputs.nixpkgs works fine (this is on my personal system) | 17:15:31 |
| balsoft | Aha, I think now I understand why it's not in runtime dependencies -- it's not in dependencies at all, so Nix doesn't even try scanning for its hash. | 17:16:43 |
| balsoft | In reply to @balsoft:balsoft.ru
Oh, ok, even more interestingly .source = inputs.nixpkgs works fine (this is on my personal system) That's because toString inputs.nixpkgs is a string with context | 17:18:27 |
| balsoft | In reply to @tomberek:matrix.org
Well…. It’s a gotcha. And easy to mess up. Not sure what would help fix it in a user-friendly way. What's the problem with making toString /some-path return a string with context? | 17:18:54 |
| balsoft | Oh, ok, that's probably because it would then break some stuff since you can't pass strings with contexts around as easily, e.g. as derivation names, correct? | 17:19:32 |
| tomberek | /some-path is not always in the store | 17:23:12 |
| balsoft | I guess I'm saying it should work the same as "${/some-path}" (which copies it to the store) | 17:24:06 |
| tomberek | This is from 2005: https://github.com/NixOS/nix/blob/master/src/libexpr/primops.cc#L3097-L3105 | 17:30:02 |
| balsoft | Aha, yes, I see why I'm wrong on that part | 17:30:39 |
| balsoft | It would break a lot of useful path operations... | 17:30:48 |
| balsoft | I remember now | 17:30:51 |
