| 23 Jun 2023 |
 sterni | In reply to @pennae:matrix.eno.space
short term, no alternative
long term, put docs awareness into nix as suggested by the docs syntax rfc that’s not a silber bullet as well | 09:18:44 |
| sterni | In reply to @fricklerhandwerk:matrix.org
What about something naive like wrapping all library functions in attribute sets and exposing just the functions as well as that large collection of metadata? extra runtime overhead | 09:19:28 |
 fricklerhandwerk | sterni: what's your take on it then? | 09:53:51 |
 pennae | In reply to @sternenseemann:systemli.org
that’s not a silber bullet as well it's closer to one than what we have now. if nix could optionally store and return, for each attribute or lambda arg, the doc comment that was attached to it we'd be golden for pretty much everything | 13:33:02 |
| pennae | doing so would cause overhead, but that can be mitigated sufficient to be just about free | 13:33:29 |
| pennae | nixdoc pr for nixpkgs manual dedocbookification is now done. we'll have to clean up the nixpkgs pr a lot before sending still
(cc asymmetric) | 13:52:55 |
| pennae | excellent, the macos build failed for unrelated reasons :D | 14:07:43 |
| pennae | nixdoc should probably sort its output, shouldn't it | 18:29:48 |
| 24 Jun 2023 |
| pennae | zmitchell: with any luck your june in docs could still include docbook removal | 21:49:37 |
| 25 Jun 2023 |
| pennae | looking at the recent prs to nix.dev ... nixos-render-docs has a lot of features from myst, which sphinx uses 🤔 | 23:55:08 |
| 27 Jun 2023 |
 @zmitchell:matrix.org | In reply to @pennae:matrix.eno.space
looking at the recent prs to nix.dev ... nixos-render-docs has a lot of features from myst, which sphinx uses 🤔 What are you suggesting? | 03:58:28 |
| @zmitchell:matrix.org | I've pushed another commit to the contributing workflow (https://github.com/NixOS/nix.dev/pull/596), but there's still open questions about the git workflow. Using a separate branch for work is less than ideal, but I don't see another way around it unless we can mark pages as drafts and have Sphinx ignore them when publishing. Most static site generators can do this by default, but I'm not sure if Sphinx can without complaining about it during builds and breaking CI. There's probably a workaround, I haven't thought about it too hard. | 04:01:07 |
| fricklerhandwerk | In reply to @zmitchell:matrix.org
I've pushed another commit to the contributing workflow (https://github.com/NixOS/nix.dev/pull/596), but there's still open questions about the git workflow. Using a separate branch for work is less than ideal, but I don't see another way around it unless we can mark pages as drafts and have Sphinx ignore them when publishing. Most static site generators can do this by default, but I'm not sure if Sphinx can without complaining about it during builds and breaking CI. There's probably a workaround, I haven't thought about it too hard. Silvan proposed dumping drafts into the maintainers directory where they are not rendered | 06:27:54 |
|  @mightyiam:matrix.org joined the room. | 09:57:54 |
| pennae | In reply to @zmitchell:matrix.org
What are you suggesting? not suggesting anything yet, but there may be a real possibility that nixos-render-docs could be used for nix.dev too. at least from a markup perspective, others (importantly: search!) would need a whole lot of work that is probably better spent doing other things | 11:58:06 |
| @zmitchell:matrix.org | In reply to @fricklerhandwerk:matrix.org
Silvan proposed dumping drafts into the maintainers directory where they are not rendered That's fine with me, we just discussed something different at the time. | 15:37:10 |
| @zmitchell:matrix.org | Is there any documentation explaining what's shown while you're building a package e.g. [1/32/39 built, 37 copied (26.4/26.5 MiB), 9.6 MiB DL]? | 17:45:28 |
| @zmitchell:matrix.org | I would expect this to show up under the nix build command, but it shows up during other operations as well | 17:45:59 |
 toonn | FWIW, I think it is current builds/finished builds/total builds. | 18:17:59 |
 asymmetric | In reply to @zmitchell:matrix.org
Is there any documentation explaining what's shown while you're building a package e.g. [1/32/39 built, 37 copied (26.4/26.5 MiB), 9.6 MiB DL]? this is one of my greatest sources of wonder, how can something as visible as this be undocumented 😂 | 20:24:42 |
| pennae | nix should really just steal nom in its entirety | 20:26:06 |
| toonn | TBF it is the UI for the experimental commands, I guess. | 20:36:28 |
 @olafklingt:matrix.org | In reply to @pennae:matrix.eno.space
nix should really just steal nom in its entirety Whats nom? | 20:58:39 |
| pennae | nix-output-monitor. really nice visualizer, miles ahead of that one line you get out of nix | 20:59:38 |
 Alex | In reply to @pennae:matrix.eno.space
nix-output-monitor. really nice visualizer, miles ahead of that one line you get out of nix You don't even get that one line without using the experimental nix3 commands :D | 22:14:20 |
 figsoda | In reply to @zmitchell:matrix.org
Is there any documentation explaining what's shown while you're building a package e.g. [1/32/39 built, 37 copied (26.4/26.5 MiB), 9.6 MiB DL]? https://github.com/NixOS/nix/issues/3352#issuecomment-584247583 | 22:51:42 |
| 28 Jun 2023 |
 Mic92 | I was thinking about pre-building nixos docs to save eval time when building nixos. | 01:55:28 |
| Mic92 | So same thing as https://github.com/nix-community/nix-index-database but for docs. | 01:55:43 |
| pennae | In reply to @joerg:thalheim.io
I was thinking about pre-building nixos docs to save eval time when building nixos. lazy options is exactly that | 01:58:20 |
| pennae | if you find more places where we can cache things then improvements are definitely welcome, but due to how nixos docs are built we think the next improvement will need flakes (or a similar mechanism for source caching) | 02:04:47 |
