| 1 Dec 2025 |
|  schromp joined the room. | 20:52:51 |
| 2 Dec 2025 |
 dr_teagle | how would I do "subflakes" mainly for devshells. I have shared dependencies in the top-level flake and then the specific dependencies lower. This is for an obsidian vault | 02:32:59 |
 K900 | Don't | 05:39:21 |
| K900 | Do multiple dev shells in one flake if you must | 05:39:30 |
 just1602 | I've colleague who did that in a couple of repos at work, and it's a mess to work with. You should really listen to k900 advise, IMO | 05:41:14 |
| dr_teagle | understandable | 05:55:16 |
 brendanzab | Hey, just wondering if there is there any consensus yet on what to do r.e. the flake freeze? i.e. https://lix.systems/blog/2025-11-18-lix-2.94-release/#flakes-enters-freeze-period and https://wiki.lix.systems/books/lix-contributors/page/flakes-feature-freeze?
Is it better just to wait and see where things go, trusting that there will be a decent migration period? | 09:44:50 |
| K900 | Don't do anything yet | 09:53:20 |
| K900 | There will be no removal of flakes without some sort of offramp | 09:53:34 |
| brendanzab | Ah, thanks! Was a little unsure from how the announcements were worded. | 09:57:52 |
 helle (just a stray cat girl) | there will also likely be a plug-in or similar situation to allow you to use flakes | 10:27:33 |
 nikstur | Is there a way I can give nix-eval-jobs an --attr flag (just like nix-build) so that it only builds a subset of packages in a file | 10:45:10 |
| nikstur | * Is there a way I can give nix-eval-jobs an --attr flag (just like nix-build) so that it only builds a subset of packages in a file? | 10:45:15 |
|  ghlent joined the room. | 10:56:28 |
 raitobezarius | --expr | 11:27:50 |
| nikstur | Ok so I have to build the expression myself, e.g. --expr '(import ./release.nix).packages' vs --attr packages. | 11:39:46 |
|  chair changed their profile picture. | 17:59:52 |
 522 it/its ⛯ΘΔ | (presumably not lix specific but im using lix so)
is there a way to always build (as opposed to just look up in the nix store) a derivation (dependencies can be substituted, that doesn't matter), without needing to just go "try --rebuild, if that fails it doesn't exist in the store, so try and build it, then use --rebuild again if that didn't actually build it)
basically, use case is for reproducible build checking, i'm considering writing a tool that just takes a .drv then builds it, then hashes the output directory and you can store the mapping from .drv to hash in a repo
| 19:51:18 |
 piegames | I fear not but it should exist really | 19:55:09 |
 llakala | i assume you already know about --check? | 19:55:57 |
| 522 it/its ⛯ΘΔ | yeah afaik that's just the same as --rebuild
you need it to be in your nix store before you can --check something | 19:56:29 |
| llakala | damn | 19:56:37 |
 aloisw | Only simplification I'm aware of is that you can omit the first step, because building should be idempotent. | 20:07:16 |
| aloisw | Arguably it would be nice if --rebuild/--check could do both build and rebuild instead of fail on nonexistent paths. | 20:08:57 |
| 522 it/its ⛯ΘΔ | what, so build (and ignore the hash) then --rebuild?
yeah that works, but it's double the work if it didn't exist | 20:09:13 |
| aloisw | Ah, so you want more a targeted --option substitute false than more convenient --rebuild? | 20:11:05 |
| 522 it/its ⛯ΘΔ | i basically want "give me an output directory that was built on this device right now", yeah | 20:12:03 |
| 522 it/its ⛯ΘΔ | so "don't give me what's in the nix store if it's in there already, don't fetch it from caches" | 20:12:20 |
| K900 | I feel like --check should even build twice by default | 20:12:27 |
| K900 | And --rebuild should build or rebuild, yeah | 20:12:34 |
