| 15 May 2024 |
 K900 | It turns out if you just let people do stuff, they will generally do cool stuff | 14:25:49 |
 mjm | a wild idea | 14:30:26 |
|  Triskelion changed their display name from Triskelion (AFK) to Triskelion. | 14:45:55 |
 DolceTriade | Will killing flake registries break nix run nixpkgs#foo? I thought that was the source for that? | 15:45:11 |
 raitobezarius | No, we would have a backup solution for that | 16:09:00 |
| raitobezarius | in the form of a static registry baked in the binary or something | 16:09:08 |
 Qyriad | No wait | 16:14:32 |
| Qyriad | We are killing the online flake registry | 16:14:45 |
 MangoIV | Oh nice | 16:15:11 |
| MangoIV | That sounds like a good idea | 16:15:20 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Yes, please kill it | 16:15:38 |
| MangoIV | Can we also haz default registries? | 16:15:42 |
| Qyriad | The user can setup nixpkgs or any other flakeref name to point to wherever they want, but the online registry should die. The static registry baked into the binary is to provide the default experience for people who have no configuration at all, so that things like nix run nixpkgs#foo still work out of the box | 16:15:44 |
| MangoIV | (I’ve used a fork for a while that did that) | 16:15:53 |
| Qyriad | In reply to@qyriad:katesiria.org
The user can setup nixpkgs or any other flakeref name to point to wherever they want, but the online registry should die. The static registry baked into the binary is to provide the default experience for people who have no configuration at all, so that things like nix run nixpkgs#foo still work out of the box Like this kind of default registry? Or do you mean something else? | 16:16:14 |
| MangoIV | In reply to @mangoiv.:matrix.org
(I’ve used a fork for a while that did that) basically you register a flake that is called “default” and then if you do nix run hello it will insert default# for you | 16:17:02 |
| MangoIV | Makes adhoc usage a bit nicer | 16:17:10 |
| MangoIV | I don’t know how it collides with the syntax though | 16:17:31 |
| Qyriad | That is, ngl, terrifying, but we do see the appeal | 16:17:40 |
 @qbit:tapenet.org | https://github.com/dramforever/nix-dram/blob/main/nix-patches/nix-flake-default.patch <-- | 16:29:38 |
| @qbit:tapenet.org | I too would like something like that | 16:29:44 |
| DolceTriade | Makes sense! | 16:29:49 |
| Qyriad | Oh it's an option hm. Well, feel free to open an issue for default-flake? | 16:30:34 |
| @qbit:tapenet.org | In reply to @qyriad:katesiria.org
That is, ngl, terrifying, but we do see the appeal what's terrifying about it? not knowing where a package comes from? | 16:30:44 |
 ma27 | given nix build foo, how would this differentiate between nixpkgs#foo and foo being an installable (e.g. a directory in the cwd with a flake.nix inside)? | 16:34:11 |
| Qyriad | In reply to@qbit:tapenet.org
what's terrifying about it? not knowing where a package comes from? Nix (including Lix) has a general problem where a big part of its entire purpose is to avoid implicit state, specifically the combination of those two. We can't avoid state, and lots of things have to happen implicitly, but we should avoid state being implicit unless there is a really really good reason. <nixpkgs> and nixpkgs in the flake registry were both considered to have sufficiently good reason: you need Nixpkgs to do literally anything. But under nix-channel, and with the online flake registry on non-NixOS, both can point to different things depending on context and from behind-the-scenes changes (on NixOS unstable, and the new release, both will point to the system's Nixpkgs thanks to Jade).
Both <> search paths and the flake registry have been rightfully criticized, but their introduction was not without reason: needing to specify a URL, even an abbrevited one like github:NixOS/nixpkgs, any time you need anything would be really fucking annoying. So there are times when implicit state is necessary for usability, but when we do, we need to be very careful when designing it so we don't fall into more traps and create more confusing caveats for users to be aware of | 16:37:18 |
| Qyriad | Does that make sense? | 16:37:22 |
| Qyriad | Nix (including Lix) has a general problem where a big part of its entire purpose is to avoid implicit state — specifically the combination of those two. We can't avoid state, and lots of things have to happen implicitly, but we should avoid state being implicit unless there is a really really good reason. <nixpkgs> and nixpkgs in the flake registry were both considered to have sufficiently good reason: you need Nixpkgs to do literally anything. But under nix-channel, and with the online flake registry on non-NixOS, both can point to different things depending on context and from behind-the-scenes changes (on NixOS unstable, and the new release, both will point to the system's Nixpkgs thanks to Jade).
Both <> search paths and the flake registry have been rightfully criticized, but their introduction was not without reason: needing to specify a URL, even an abbrevited one like github:NixOS/nixpkgs, any time you need anything would be really fucking annoying. So there are times when implicit state is necessary for usability, but when we do, we need to be very careful when designing it so we don't fall into more traps and create more confusing caveats for users to be aware of | 16:38:04 |
 strawberry🍓 (it/pup/she/they) 🏳️⚧️ 💜 🦴 (puppygock.gay) | (makes sense to me and i barely know or use nix/lix 😇) | 16:38:51 |
| @qbit:tapenet.org | makes sense! thanks for the explanation :D | 16:39:18 |
