| 22 Jun 2023 |
 fricklerhandwerk | In reply to @pennae:matrix.eno.space
the nixdoc approach to finding docs is just ... wrong, really :/ What would you suggest instead? | 20:25:07 |
 pennae | short term, no alternative
long term, put docs awareness into nix as suggested by the docs syntax rfc | 20:26:18 |
| pennae | looks like we got it working again with mostly the same semantics as the old nixdoc, but it's very fragile :( | 20:29:22 |
| pennae | it's not realistically possible to extract function docs from nix files without evaluating them, if it's not in nix itself there will always be confusing corner cases. we're not super hopeful that it'll end up being added to nix because the use case is disproportionately small compared to the cost of having that functionality. we may have to codify lib docs syntax somehow else instead | 20:35:41 |
| 23 Jun 2023 |
| fricklerhandwerk | 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? | 06:31:40 |
| fricklerhandwerk | Also there still exists the ominous __functor | 06:36:00 |
 sterni | In reply to @pennae:matrix.eno.space
it does look totally possible, but not something we can easily fit into the docbook removal process that’s fine but it probably only makes sense to do after that is finished | 09:17:27 |
| 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 |
