!avYyleMexqjFHoqrME:nixos.org

Nix Documentation

415 Members
Discussion about documentation improvements around the Nix ecosystem85 Servers

Load older messages


SenderMessageTime
16 Mar 2024
@ryantm:matrix.orgryantmand your thing is already working mostly, though not multipage.05:30:23
@ryantm:matrix.orgryantmSeems reasonable not to switch.05:30:26
@infinisil:matrix.orginfinisilI feel kind of bad, you worked on this for so long 😅05:31:07
@ryantm:matrix.orgryantmI'll take down my multipage manual when we publish official ones.05:31:08
@ryantm:matrix.orgryantmNo big deal, I still love the project independent of Nix accepting it.05:31:34
@ryantm:matrix.orgryantmI use it for all my projects and blogs and stuff.05:31:44
@ryantm:matrix.orgryantmI love the easy interface with no config I came up with.05:31:59
@jade_:matrix.org@jade_:matrix.org
In reply to @ryantm:matrix.org
and your thing is already working mostly, though not multipage.
I've been told the code is literally there for it, though. so we seem to need to do some wiring. 
07:41:14
@pennae:matrix.eno.spacepennae joined the room.09:23:50
@pennae:matrix.eno.spacepennae(infinisil requested our presence :D)09:24:07
@fricklerhandwerk:matrix.orgfricklerhandwerk
In reply to @rina/:matrix.org
i am starting to see that. though, i do not mind pitching in where i can :)

What would you be interested in taking a closer look at? It would also help knowing what you may have had experience with already, to find something that won’t overwhelm or frustrate you too quickly. Feel free to DM me if you don’t want this public.

Not everything needed to get started is written down nicely yet, so I can offer a brief guided tour of the various construction sites.

14:06:41
@rina/:matrix.orgkaithm off the top of my head, there are gaps around the trivial script writers - both in terms of documentation and the options they provide14:12:30
@rina/:matrix.orgkaiti mainly use nix outside nixos, and much of my packaging experience is with C/C++ and cmake. maybe more documentation on dealing with cmake external projects would be useful too14:14:06
@rina/:matrix.orgkaitbut these are just items i have had the need for in the past, I can try to help out elsewhere if able14:24:07
@rina/:matrix.orgkaitI'm actually heading to sleep now (in Australia), but I will read any replies tomorrow14:24:28
@fricklerhandwerk:matrix.orgfricklerhandwerk
In reply to @rina/:matrix.org
i mainly use nix outside nixos, and much of my packaging experience is with C/C++ and cmake. maybe more documentation on dealing with cmake external projects would be useful too

There is a wealth of information here: https://nixos.wiki/wiki/C

Mostly written by @Mic92 in past years AFAIK. Would be great to have that closer to the code, because all of that is Nixpkgs material.

We still haven't really figured out how to organise troubleshooting tips and other guide-like material across the ecosystem though. The last state of affairs was that we converged on the idea that it should be a bit like what Johannes Kirschbauer @hsjobeki proposes for function documentation, but for guides: have a uniform format used across Nix, Nixpkgs, and NixOS, and present that in one place, annotated with tags and searchable. But that is a lot of "should", and will require thinking about the structure of the manuals, and moving around lots of text.

15:27:15
@fricklerhandwerk:matrix.orgfricklerhandwerk
In reply to @rina/:matrix.org
hm off the top of my head, there are gaps around the trivial script writers - both in terms of documentation and the options they provide

Those were recently improved:

  • https://github.com/NixOS/nixpkgs/pull/280592
  • https://github.com/NixOS/nixpkgs/pull/277534

But there's definitely still work to do. Ideally we'd also render that stuff directly from the source. At least there is no duplication any more. I can imagine danielsidhion could help with reviews.

15:31:48
@fricklerhandwerk:matrix.orgfricklerhandwerk
In reply to @rina/:matrix.org
i mainly use nix outside nixos, and much of my packaging experience is with C/C++ and cmake. maybe more documentation on dealing with cmake external projects would be useful too
*

There is a wealth of information here: https://nixos.wiki/wiki/C

Mostly written by @Mic92 in past years AFAIK. Would be great to have that closer to the code, because all of that is Nixpkgs material.

We still haven't really figured out how to organise troubleshooting tips and other guide-like material across the ecosystem though. The last state of affairs was that we converged on the idea that it should be a bit like what Johannes Kirschbauer @hsjobeki proposes for function documentation, but for guides: have a uniform format used across Nix, Nixpkgs, and NixOS, and present that in one place, annotated with tags and searchable. But that is a lot of "should", and will require thinking about the structure of the manuals, moving around lots of text, and building automation for presenting the result.

15:32:40
@johannes.kirschbauer:scs.ems.host@johannes.kirschbauer:scs.ems.host Since #280592 The documentation is not closely connected to the source anymore. The doc-comment was replaced by an explicit markdown document. Which is fine but we should have a more distinct way of creating a reference to the document such that a doc-comment tool knows that the documentation exists but is located at a different place.
We actually will need some more of those „rediretcion-directives“. One task is to research if there are usable standards for that (i some how doubt that) or to come up with a good solution on our own.
16:19:51
@johannes.kirschbauer:scs.ems.host@johannes.kirschbauer:scs.ems.host* Since #280592 The documentation of ‚writeShellApplication’ is not closely connected to the source anymore. The doc-comment was replaced by an explicit markdown document. Which is fine but we should have a more distinct way of creating a reference to the document such that a doc-comment tool knows that the documentation exists but is located at a different place.
We actually will need some more of those „rediretcion-directives“. One task is to research if there are usable standards for that (i some how doubt that) or to come up with a good solution on our own.16:20:22
@johannes.kirschbauer:scs.ems.host@johannes.kirschbauer:scs.ems.host* Since #280592 The documentation of ‚writeShellApplication’ is not closely connected to the source anymore. The doc-comment was replaced by an explicit markdown document. Which is fine but we should have a more distinct way of creating a reference to the document such that a doc-comment tool knows that the documentation exists but is located at a different place.
We actually will need some more of those „rediretcion-directives“. One task is to research if there are usable standards for that (i somehow doubt that) or to come up with a good solution on our own.16:20:56
@danielsidhion:nixos.devdanielsidhionI can help review anything related to nixpkgs manual. Prepending "doc:" to the PR title is the easiest way to get my attention (I keep track of every PR that follows this), but pinging me or requesting review directly from me also does the job16:59:26
@fricklerhandwerk:matrix.orgfricklerhandwerk
In reply to @johannes.kirschbauer:scs.ems.host
Since #280592 The documentation of ‚writeShellApplication’ is not closely connected to the source anymore. The doc-comment was replaced by an explicit markdown document. Which is fine but we should have a more distinct way of creating a reference to the document such that a doc-comment tool knows that the documentation exists but is located at a different place.
We actually will need some more of those „rediretcion-directives“. One task is to research if there are usable standards for that (i somehow doubt that) or to come up with a good solution on our own.
With nixdoc taking shape, does anything speak against systematically moving that text into the code?
17:18:28
@johannes.kirschbauer:scs.ems.host@johannes.kirschbauer:scs.ems.hostIt would still be nice for longer documents like those for stdenv & mkDerivation.17:20:40
@danielsidhion:nixos.devdanielsidhion
In reply to @fricklerhandwerk:matrix.org
With nixdoc taking shape, does anything speak against systematically moving that text into the code?
There are a few tricky cases that we'll need to handle that requires more thought before doing it right away (one that we already encountered is function with doc-comment that documents inputs, but then more doc-comments on each function argument)
17:21:19
@danielsidhion:nixos.devdanielsidhionThose cases (and what we're doing with them) aren't documented right now, and the way we handle these will likely change in the future, which is why we're being a bit conservative with the move17:23:02
@pennae:matrix.eno.spacepennae oh wow we only now get to see the backlog. someone asked about multipage rendering in nrd it seems? html:into-file makes that happen, the manual already uses that to render the option docs and appendix. isn't automated per chapter/part, but could be added easily (the infra to do this is there already) 18:13:51
@pennae:matrix.eno.spacepennae getting the official manual to render multipage is literally just sprinkling html:into-file directives on the includes and letting it build 18:14:46
@pennae:matrix.eno.spacepennae(which, we do want to stress at the risk of offending someone, we have said at least five different times, including in meetings of the docs team)18:15:58
@johannes.kirschbauer:scs.ems.host@johannes.kirschbauer:scs.ems.host(Without also offending) Was it a lack of contributions? or why don't we have a multi-page outut if it's trivial and has been said so many times? It would be interesting to know whats the root cause then.18:56:19

Show newer messages


Back to Room ListRoom Version: 6