| 13 Apr 2026 |
 raitobezarius | there is | 19:33:19 |
| raitobezarius | we made auto-allocate-uid dependent on cgroups | 19:33:32 |
| raitobezarius | because killing things under a uid is annoying under linux without cgroups | 19:33:44 |
 whispers [& it/fae] | ah, makes sense. thanks! | 19:35:14 |
 Charles | TIL { __toString = self: ...; } | 20:38:32 |
 zoë (she/her) | wait til you hear about { outPath = "foo"; } + "/bin/hello" and { __functor = self: ...; } :D | 20:39:54 |
| zoë (she/her) | * wait til you hear about { outPath = "foo"; } + "/bin/hello" and functors ({ __functor = self: ...; }) :D | 20:40:15 |
| Charles | i knew about functor already actually | 20:40:20 |
| Charles | that + is scuffed though lol | 20:40:31 |
| Charles | it makes sense but still | 20:40:52 |
| zoë (she/her) | yep, especially because that value is not a path according to the builtins (isPath {...} = false, isAttrs {...} = true), which makes it really transparent in some cases while still breaking down when it's least convenient (e.g. trying to use a derivation (which, for most cases, is any set with outPath) as a nixpkgs module) | 20:43:43 |
| zoë (she/her) | * yep, especially because that value is not a path according to the builtins (isPath {...} = false, isAttrs {...} = true), which makes it really transparent in some cases while still breaking down when it's least convenient (e.g. trying to use a derivation (which, for most cases, is any set with outPath) as a nixpkgs module, because the module system uses builtins.isPath but never foo?outPath) | 20:45:16 |
| zoë (she/her) | so, for example, trying to directly put a pin from npins into a module's import list doesn't work; instead, you need to explicitely use .outPath on it:
{ ... }:
let pins = import ./npins {}; in {
imports = [
pins.press # doesn't work
pins.nix-z4h.outPath # works
];
}
| 20:47:13 |
| Charles | oh, that's silly | 20:47:57 |
| Charles | i assume there's a good reason why this hasn't been changed? | 20:48:05 |
| zoë (she/her) | * so, for example, trying to directly put a pin from npins into a module's import list doesn't work; instead, you need to explicitely use .outPath on it:
{ ... }:
let pins = import ./npins {}; in {
imports = [
pins.press # doesn't work
pins.nix-z4h.outPath # works
];
}
| 20:48:32 |
| Charles | nix-repl> builtins.getContext (builtins.toString <nixpkgs>)
{ }
nix-repl> builtins.getContext "${<nixpkgs>}"
{
"/nix/store/bwdc9wx2vwdawf6pfv6kcdjc4lz87nhb-anvdcc2arw7kqrvwnidvhw6ypkkvws68-source" = { ... };
}
nix-repl> <nixpkgs>
/nix/store/anvdcc2arw7kqrvwnidvhw6ypkkvws68-source
tangentially related, this was interesting. also that second expr took a very long time to run
| 20:48:38 |
| zoë (she/her) | worst part is that if you wrote ${pins.press} instead, it would have worked just fine ;-; | 20:49:08 |
| zoë (she/her) | * worst part is that if you wrote ${pins.press} instead, it would work just fine ;-; | 20:49:14 |
| zoë (she/her) | i have no idea; i assume there is, but i've never seen a nixpkgs issue for it and i've been too lazy to make one and fight against whatever inevitable nitpicking/bikeshedding would occur (especially since i knew zilch about the module system) | 20:50:33 |
| Charles | lol reasonable | 20:50:52 |
| zoë (she/her) | yeah, toString and interpolation resulting in differently-contexted strings is another biiiig footgun 🙃 | 20:51:19 |
| zoë (she/her) | it has bit me many times before :/ | 20:51:32 |
| zoë (she/her) | but it's also kinda load bearing | 20:51:45 |
| zoë (she/her) | the most frustrating part is mostly when using other's code (including nixpkgs), since then you have to go digging into every function to know whether or not the drv/path you're passing gets interpolated or toString'd | 20:52:37 |
| zoë (she/her) | * the most frustrating part is mostly when using other's code (including nixpkgs), since then you have to go digging into every function to know whether or not the drv/path you're passing gets interpolated or toString'd, and there's some contexts/applications where that really matters | 20:53:18 |
| Charles | oof | 20:53:27 |
| zoë (she/her) | (also yeah i've also noticed getContext taking a bit of time in the past, though i had always assumed that was either just an illusion or a personal thing; it might just be because it's computing/instantiating the derivation?) | 20:55:55 |
| Charles | i think that's why, yeah | 20:56:09 |
| Charles | because the store path it outputs is weird i assume it's making another copy of nixpkgs, at minimum, which isn't the fastest thing to do | 20:56:42 |
