| 23 Feb 2024 |
 maralorn | Philip Taron (UTC-8): Certainly, quite a few people do it. | 08:59:46 |
| maralorn | The easiest way right now is to run nom-build on the system closure expression right before running nixos-rebuild. | 09:00:37 |
| maralorn | I think to really use nom in nixos-rebuild we need to add a tiny bit of behavior to nom. | 09:01:31 |
| maralorn | I will get to it sometime this year. | 09:01:50 |
 Philip Taron (UTC-8) | In reply to @maralorn:maralorn.de
I think to really use nom in nixos-rebuild we need to add a tiny bit of behavior to nom. What're you thinking? | 16:20:55 |
| maralorn | If I remember correctly nixos-rebuild calls a few nix commands which are currently not supported by the nom drop in. | 16:24:48 |
| maralorn | I fix would be trivial, but I never dared to approach that because it requires adding nom specific plumbing directly in the nixpkgs code. Although at this point I think nom has so much traction in the community that opt-in nom support in nixos-rebuild would probably be accepted. | 16:27:19 |
| maralorn | * A fix would be trivial, but I never dared to approach that because it requires adding nom specific plumbing directly in the nixpkgs code. Although at this point I think nom has so much traction in the community that opt-in nom support in nixos-rebuild would probably be accepted. | 16:27:25 |
| Philip Taron (UTC-8) | It looks like there's just one place that nix-build is called in nixos-rebuild. I'll see if I can substitute it in my own overlay. | 16:28:22 |
| Philip Taron (UTC-8) | (Thank you for nom, btw. Beautiful piece of work.) | 16:29:26 |
| maralorn | Philip Taron (UTC-8): If you find that a specific change in nom would be helpful, please let me know. | 16:29:46 |
 K900 | I'm pretty sure it should be very easy to add | 16:30:12 |
| maralorn | Also if you find some solution which could reasonably be upstreamed into nixpkgs, that would be awesome. | 16:30:14 |
| maralorn | K900 ⚡️: I also think so. | 16:30:35 |
| K900 | I've read nixos-rebuild like two days ago | 16:31:07 |
| 25 Feb 2024 |
|  @qbit:tapenet.org joined the room. | 20:14:06 |
| @qbit:tapenet.org | hi! | 20:14:34 |
| @qbit:tapenet.org | is there a way to completely disable color output? | 20:14:44 |
| maralorn | qbit: Currently not, now. | 21:57:23 |
| maralorn | Why would you want that? | 21:57:33 |
| maralorn | incidentally: Even if I disable the colors in nom the nix build log could still contain colors. | 21:58:00 |
| maralorn | You can open a feature request issue on github. | 21:58:52 |
| maralorn | Currently nom is not very configurable, but once it is a flag like that would be easy to add. | 21:59:16 |
| @qbit:tapenet.org | In reply to @maralorn:maralorn.de
Why would you want that? Lots of reasons - big ones being color blind people and non-dark terminals | 22:06:29 |
| maralorn | qbit: Fair, it’s a reasonable request and I will provide that nob when I get to it. Just wanted to point out that both of these scenarios can imo be solved by configuring a good color theme in the terminal. The nom color theme is not optimized for dark terminals, in fact I developed it on a light terminal. nom only uses the 16 basic colors which are set by the terminal. Imo every user should set those default colors to a palette which provides a good contrast in their setup. Although I assume for color blind people that’s likely not completely achievable … | 22:14:48 |
| @qbit:tapenet.org | Not sure what color lib is in use but a number of them support the NO_COLOR env var: http://no-color.org/ | 22:31:56 |
| maralorn | qbit: Well, our library doesn’t support it. But implementing that standard seems very reasonable and not hard at all. | 22:56:38 |
| maralorn | http://no-color.org/ | 23:39:26 |
| maralorn | * https://github.com/maralorn/nix-output-monitor/issues/129 | 23:39:34 |
| 29 Feb 2024 |
|  maka_77x joined the room. | 00:52:08 |
