In reply to @ronef:matrix.org
Johannes Kirschbauer @hsjobeki: see if there's anything you'd want to add here about it
Are you going to be around at NixCon?
https://docs.google.com/presentation/d/1G9Rc6cxWKgMM1q0DtgwyWUauBZ0vBLhAiV3M5ZuvEyo/edit#slide=id.g23efee59dda_0_212

In reply to @johannes.kirschbauer:scs.ems.host
@fricklerhandwerk:matrix.org: do we want to add nix-documentation team Slide? There was quite some stuff Happening this year. Stuff for reference documentation - Jan noogle 2024 released - doc-comments now implemented in nix-repl (roberth ported from lix i think) - Infra / Domain Changed (you did this i think with roberth) - multi Version nix Manual - nix.dev (i dont know what Majors happened there) ... Maybe we should sit down and Filter Out the important stuff?

Just a quick question about the lib type signatures - is it an active decision we have made not to note subtypes for attrsets? Or has it just become this way?

# Current state for lists
map :: (a -> b) -> [a] -> [b]

# Current state for attrs
mapAttrs :: (String -> Any -> Any) -> AttrSet -> AttrSet

# I'd like something like this
mapAttrs :: (String -> a -> b) -> { * :: a } -> { * :: b }

# Or alternatively just
mapAttrs :: (String -> a -> b) -> { a } -> { b }

In reply to @johannes.kirschbauer:scs.ems.host
@ronef:matrix.org: i am going on train now. A little Community effort to finish with doc-comments migration would be so nice. Its been a huge milestone and is actually very easy. But a lot of handwork is required. I could make a little guide for how to do it with the hope that some people are willing to jump in for the missing mile

In reply to @johannes.kirschbauer:scs.ems.host
@ronef:matrix.org: i am going on train now. A little Community effort to finish with doc-comments migration would be so nice. Its been a huge milestone and is actually very easy. But a lot of handwork is required. I could make a little guide for how to do it with the hope that some people are willing to jump in for the missing mile

In reply to @h7x4:nani.wtf

Just a quick question about the lib type signatures - is it an active decision we have made not to note subtypes for attrsets? Or has it just become this way?

# Current state for lists
map :: (a -> b) -> [a] -> [b]

# Current state for attrs
mapAttrs :: (String -> Any -> Any) -> AttrSet -> AttrSet

# I'd like something like this
mapAttrs :: (String -> a -> b) -> { * :: a } -> { * :: b }

# Or alternatively just
mapAttrs :: (String -> a -> b) -> { a } -> { b }

Hey all! I've been developing sphinxcontrib-nixdomain these past months,
which is a project for documenting Nix "objects" in the Sphinx documentation system.

Currently it only support NixOS options, but I plan on adding support for packages and libs.
It's currently missing some documentation (heh) and it's not currently published on PyPi,
but I think it'd be quite a useful project for non-nixpkgs Nix projects.

Here's an example of what it looks like in a real project: https://epics-extensions.github.io/EPNix/nixos-services/options-reference/archiver-appliance.html

Is this something you'd be interested in?
I think I'll be needing help for example to fetch doc comments like nixdoc does.

In reply to @fricklerhandwerk:matrix.org
We can already try without any of that and see how it goes, no need to block. Could you open a PR to use it on some page? Eg the first section of the module system tutorial and render the example module

In reply to @Minijackson:matrix.org
Note that right now, the project is only useful for project that define their own NixOS option. I'd like to make a Sphinx role for referring to options defined in nixpkgs, but it's not implemented right now

In reply to @fricklerhandwerk:matrix.org
If it works via optionsDoc and one can pass a config it should be easy to just hand it anything, including NixOS stuff, right?