| 20 Dec 2025 |
pentane (DECT CYPT/2978) | although afaict from a theoretical standpoint, this matches the semantics of dynamic derivations better than IFD | 14:26:52 |
piegames | now that you say all of this, maybe k900 has a point :p | 14:27:06 |
pentane (DECT CYPT/2978) | yeah I also agree with K900 | 14:27:51 |
pentane (DECT CYPT/2978) | another missing puzzle piece imo: currently, Nix treats the eval process and the build process as two conceptually separate things. But afaict there's nothing stopping us from treating the evaluation of, say, a flake as a derivation too - that derivation would have the flake source, its dependencies and nix as inputs, and output a .drv file | 14:30:22 |
pentane (DECT CYPT/2978) | once you've got it set up that way, IFD and dynamic derivations basically are the same thing | 14:31:10 |
pentane (DECT CYPT/2978) | and you get expression language agnosticism for free, since you can then use everything that produces .drv files as an expression language for Nix and not just Nixlang | 14:31:59 |
pentane (DECT CYPT/2978) | thank you for coming to my ted talk | 14:32:04 |
piegames | Basically from the eval side of things this will be a form of async, where eval halts when it needs the result of a derivation and proceeds once that derivation is built, comparable to waiting for IO | 14:33:01 |
piegames | TIL nix-build <nixpkgs> works even without --expr for some reason | 14:53:07 |
K900 | Attrset build target nonsense? | 14:53:39 |
K900 | Which is a thing you may actually want | 14:58:12 |
piegames | yes but | 15:02:40 |
Acid Bong | In reply to @piegames:flausch.social TIL nix-build <nixpkgs> works even without --expr for some reason because resolves into a filepath entry from NIX_PATH named abc
same thing as nix-build src/nixpkgs | 15:40:18 |
Acid Bong | * because `<abc>` resolves into a filepath entry from NIX_PATH named abc
same thing as `nix-build src/nixpkgs`
| 15:40:52 |
piegames | yes I understand that | 15:49:14 |
piegames | but I find this "fileish" thing weird | 15:49:53 |
Sofie 🏳️⚧️ (she/her) | So anyways, does someone have a nice template which covers agenix or another secret thingy, directory centered modules and options, system deployment and other stuff | 16:54:02 |
Sofie 🏳️⚧️ (she/her) | * | 16:54:50 |
Sofie 🏳️⚧️ (she/her) | For Nilla | 16:55:18 |
Sofie 🏳️⚧️ (she/her) | @jakehamilton:auxolotl.org do you have an example of Nilla but with agenix or similar? | 17:00:15 |
Sofie 🏳️⚧️ (she/her) | I love your Hive based config :3 | 17:00:25 |
bandithedoge | is there a way to make the lix installer not try to install fish configs? it's causing this error in my github action that uses nothing-but-nix with default settings: https://github.com/bandithedoge/nur-packages/actions/runs/20227877364/job/58063479258#step:4:83 | 17:24:38 |
goldstein | nix-repl> builtins.flakeRefToString { type = "indirect"; id = "lol"; ref = "lol/9bdfd23e28ffc1fb5a6e52e43dad4288701bb05d"; }
"flake:lol/lol/9bdfd23e28ffc1fb5a6e52e43dad4288701bb05d"
nix-repl> builtins.flakeRefToString { type = "indirect"; id = "lol"; ref = "lol"; rev = "9bdfd23e28ffc1fb5a6e52e43dad4288701bb05d"; }
"flake:lol/lol/9bdfd23e28ffc1fb5a6e52e43dad4288701bb05d
no question here, I just want to share my pain 🫠
why are flakerefs so ambiguous | 18:54:59 |
goldstein | I knew that parse(serialize(flakeref)) is not noop because of HTTP query params, but I didn’t know that indirect flakerefs are also ambigous | 18:59:00 |
goldstein | and getFlake only takes string flakerefs, so some getFlake invocations are quite literally inexpressible | 18:59:37 |
goldstein | nix-repl> builtins.parseFlakeRef (builtins.flakeRefToString { type = "indirect"; id = "nixpkgs"; ref = "refs/heads/master"; })
error:
… while calling the 'parseFlakeRef' builtin
at «string»:1:1:
1| builtins.parseFlakeRef (builtins.flakeRefToString { type = "indirect"; id = "nixpkgs"; ref = "refs/heads/master"; })
| ^
error: GitHub URL 'flake:nixpkgs/refs/heads/master' is invalid
that one is probably a bug though? no way it’s a github url | 19:06:51 |
Sofie 🏳️⚧️ (she/her) | also, rootless install through nixsa would be nice to have! | 19:48:40 |
bandithedoge | real | 19:49:12 |
raitobezarius | In reply to @cyclopentane:aidoskyneen.eu another missing puzzle piece imo: currently, Nix treats the eval process and the build process as two conceptually separate things. But afaict there's nothing stopping us from treating the evaluation of, say, a flake as a derivation too - that derivation would have the flake source, its dependencies and nix as inputs, and output a .drv file I also have this in my mind and I'd like it to happen | 23:47:22 |
| 21 Dec 2025 |
SomeoneSerge (back on matrix) | It's more like aterm drv and nixlang are two different languages and both are by default applicative, with ifd making nixlang monadic and dyndrv making aterm monadic. But also I've never managed to read "a la carte" as anything more than a bunch of handwavy metaphors when applied to nix, so idk, maybe I'm too slow for this | 01:17:51 |