| 31 Dec 2023 |
 danielsidhion | In reply to @aos1:matrix.org
Hey y'all - quick question: is there a way to build the nixpkgs manual using the provided flake? I see in https://github.com/NixOS/nixpkgs/blob/34d3d09834b52db5da25fb6f36055f4971709ee3/flake.nix#L57-L62 that the output: htmlDocs is exposed, but I don't think it's possible to build it? I tried nix build .#htmlDocs on a local checkout of nixpkgs repo, but that doesn't work htmlDocs is not a derivation - the error you got when running nix build .#htmlDocs says exactly that. If you look at the definition of htmlDocs in the flake, you'll see it specifies the nixpkgsManual and nixosManual attributes, and those are derivations you can build | 17:36:55 |
| danielsidhion | Try nix build .#htmlDocs.nixpkgsManual or nix build .#htmlDocs.nixosManual | 17:37:12 |
 aos | Ohhh... that makes total sense. I should've read the error better. Thank you :-) | 17:38:17 |
|  Philip Taron (UTC-8) changed their display name from Philip Taron to Philip Taron (UTC-8). | 18:10:48 |
| 1 Jan 2024 |
|  @nixinator:nixos.dev left the room. | 22:37:04 |
| 2 Jan 2024 |
 asymmetric | https://jvns.ca/blog/2024/01/01/some-notes-on-nixos/ | 11:19:49 |
| asymmetric | i always find it useful to see what other people use to learn (how to do things with) nix, that's why i post it here | 11:25:57 |
| asymmetric | it would be good to track how many new articles use nix.dev instead of the wiki. this uses the wiki | 11:26:55 |
| asymmetric | but for something that i'm not sure we should be maintaining ourselves? it seems like for things like "nixos friendly hosters", a wiki provides less friction | 11:27:48 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction | 11:27:57 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes off some work from the docs team | 11:28:18 |
| asymmetric | or is the idea that everything that's now in nix.wiki + nixlang.wiki should eventually be absorbed by nix.dev? | 11:28:52 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes off some work from the docs team's plate | 11:29:10 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes some work off the docs team's plate | 11:29:18 |
 fricklerhandwerk | In reply to @asymmetric:matrix.dapp.org.uk
or is the idea that everything that's now in nix.wiki + nixlang.wiki should eventually be absorbed by nix.dev? Absolutely not. We certainly need a place for a class of crowd-maintained information, everything else is not manageable. | 14:03:47 |
| asymmetric | In reply to @fricklerhandwerk:matrix.org
Absolutely not. We certainly need a place for a class of crowd-maintained information, everything else is not manageable. do we have some rough principle of what should not go into nix.dev? i can think of "anything that doesn't fit diàtaxis", but that seems a bit unsatisfying | 14:37:08 |
| fricklerhandwerk | A few unstructured thoughts:
-
instructions for specific software
This is currently covered by the wiki to some extent, by NixOS/Home
Manager/… option documentation, and upstream
-
reference documentation
That should be in the manual for the respective component. There are a few violations of that at the moment
Conversely, what should go into nix.dev are things that don’t fit anywhere else: cross-cutting concerns that aren’t specific to any ecosystem component or don’t have a better place to live. Ideally that would be very little. | 15:26:34 |
| asymmetric | but we've just moved the nix ref manual to nix.dev? | 15:30:59 |
| fricklerhandwerk | In reply to @asymmetric:matrix.dapp.org.uk
but we've just moved the nix ref manual to nix.dev? This just where it’s hosted. I read your question as “which content should be part of the nix.dev source” | 15:56:55 |
| asymmetric | yeah good point | 15:57:44 |
| 3 Jan 2024 |
 @jade_:matrix.org | imo: our module system docs are faulty, in that you can't write guide level stuff in them | 12:49:01 |
| @jade_:matrix.org | which is a symptom of "services.jellyfin" or whatever not being a distinct entity in the module system and thus you can't attach docs to it | 12:49:29 |
| @jade_:matrix.org | it would be sick if we could attach docs to such things | 12:49:42 |
 @qyriad:matrix.org | Oh that would be fantastic | 12:54:06 |
 raitobezarius | Same for changelogs in practice | 14:03:11 |
|  nikstur changed their display name from nikstur (DECT 5643) to nikstur. | 15:33:23 |
 Chris McDonough | i'm going to try to join the the nix documentation meeting tomorrow; can someone acknowledge that they see this message | 19:49:52 |
| Chris McDonough | ty! | 20:06:39 |
 @johannes.kirschbauer:scs.ems.host | I'll join the meeting as well. I could need some help with migration of the nixpkgs manual rendering. (nixos-render-docs)
There are a lot of questionmarks in my head when it comes to section ids.
I'd like to discuss the future of that tooling after rfc145 was merged. Who has the ownership about this? @pennae or fricklerhandwerk ?
| 20:52:25 |
| @johannes.kirschbauer:scs.ems.host | * I'll join the meeting as well. I could need some help with migration of the nixpkgs manual rendering. (nixos-render-docs)
There are a lot of questionmarks in my head
I'd like to discuss the future of that tooling after rfc145 was merged. Who has the ownership about this? @pennae or fricklerhandwerk ?
| 20:52:39 |
