| 12 Jan 2024 |
 Chris McDonough | ok, i think that makes sense | 16:49:59 |
| Chris McDonough | in that trivial builders file, we have sort of haskell-style "runCommand :: String -> AttrSet -> String -> Derivation" style of documenting inputs and outputs... i'm going to remove those and go with that | 16:51:23 |
 infinisil | danielsidhion: https://github.com/NixOS/nixos-homepage/pull/1199 | 16:52:46 |
 danielsidhion | If that style of documenting inputs/outputs doesn't work well for your use case, please help improve the conventions by either adding more specific cases or helping find a common abstraction that works for more cases | 16:53:22 |
| danielsidhion | We're kind of making those conventions as I find the opportunities while working on the manual | 16:53:38 |
| Chris McDonough | yep... i don't personally think the "runCommand :: String -> AttrSet -> String -> Derivation" style is very useful so i'll replace it with what we talked about and we'l see what happens :) | 16:54:31 |
| Chris McDonough | if CI completes, could we merge https://github.com/NixOS/nixpkgs/pull/277534 as-is so far? rationale: i don't want to make more commits to it that are unrelated to the writeText* functions, which is what its about right now | 17:24:55 |
| Chris McDonough | (i'd like to make more changes to it that are related to function argument styles) | 17:25:15 |
| Chris McDonough | (but that are not related to writeText* funcs) | 17:25:46 |
| danielsidhion | I'm reviewing the pr right now | 17:33:26 |
 @jade_:matrix.org | In reply to @asymmetric:matrix.dapp.org.uk
i think we would really benefit from this. it would make it easier for people to contribute across the different projects on the platform, create links when appropriate, etc etc there's a bunch of efforts of unclear relation involving writing new docs builders. we really need to write down what they are and probably make a tracking issue to try to not step on our own toes. | 18:20:29 |
| infinisil | danielsidhion: Manual is now being updated again! https://nixos.org/manual/nixpkgs/unstable/ | 19:40:43 |
| infinisil | (merged the PR and manually triggered an update) | 19:40:56 |
| danielsidhion | Thank you for fixing it! | 19:41:26 |
| danielsidhion | In reply to @jade_:matrix.org
there's a bunch of efforts of unclear relation involving writing new docs builders. we really need to write down what they are and probably make a tracking issue to try to not step on our own toes. I think that's important, added this to the agenda for next meeting so it's not forgotten to be at least discussed, hopefully the issue is created during the meeting though | 19:43:53 |
 asymmetric | jade_: what projects/efforts are you thinking of? i know of nixos-render-docs (which is actually used in nixpkgs/nixos), mmdoc (which was supposed to be used, but isnt'). anything else? | 20:40:07 |
| asymmetric | relatedly, i was looking into the pr splitting the nixpkgs manual up, which uses mmdoc, and i think it should probably be re-implemented using nrd? | 20:49:44 |
| asymmetric | mainly because, afaict, nrd is the sanctioned way forward | 20:50:34 |
| @jade_:matrix.org | this one, which claims to "complete autogenerated documentation for the whole nix-ecosystem" (which is fundamentally contradictory with all the other projects ostensibly doing this but having nothing to do with it): https://github.com/nix-community/docnix | 20:53:12 |
| @jade_:matrix.org | the description of this and how it fits into the way everything is going to fit together is very fundamentally confusing | 20:53:54 |
| @jade_:matrix.org | and i guess this is part of a meta thing of "we aren't tracking how all the new docs stuff is fitting together and what we actually want from a docs generation system that fulfils all requirements" | 20:55:01 |
| @jade_:matrix.org | (for the record i don't think that we are going to get away with having something that doesn't have very substantial amounts of our own code, in spite of what may have been said about that objective in the past re using sphinx or such. at the very least we will have to have a plugin or such) | 20:56:26 |
| @jade_:matrix.org | In reply to @asymmetric:matrix.dapp.org.uk
mainly because, afaict, nrd is the sanctioned way forward gosh we need to write these things down in a durable location that is not a github issue. we need a not-necessarily-wiki but easily modified, page that states that decision, and in general an overview of the tooling and its plans | 20:59:24 |
