Nix Documentation | 439 Members | |
| Discussion about documentation improvements around the Nix ecosystem | 93 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Jun 2023 | ||
| * I'm a software developer and I care about derivations. I believe many software developers would care about creating their own derivations for whatever projects they work on. This is especially true for complex polyglot projects that would otherwise have a number of moving parts without "packing" them into a derivation. Moreover, creating derivations for your own projects comes with a number of benefits such as package deployment and distribution, dependency management and versioning and isolation for testing purposes, which would be useful for a large of subset of software development teams. I find it interesting that out of all topics I mentioned you picked derivations to criticise, since it is arguably has the most utility compared to everything else that I've listed. | 23:29:43 | |
| * The most illuminating piece of exposition that I've seen was this Reddit post that gave me a good understanding of it: https://www.reddit.com/r/NixOS/comments/13ye3lg/what_are_the_advantages_of_using_flakes/ | 23:30:44 | |
| * For the longest time I couldn't understand what flakes were and what utility it provided over using a nix shell. | 23:30:49 | |
| 19 Jun 2023 | ||
toonn might be talking about raw derivations rather than builders like stdenv.mkDerivation which is what a developer is much more likely to use | 08:49:09 | |
| I like this explanation of the build process, would be nice if we could have something similar on nix.dev https://news.ycombinator.com/item?id=36388251 | 08:59:52 | |
| I'm talking about derivations, which are the product of something like a call to mkDerivation and contains the concrete information Nix uses to build something. I didn't know DominicMills was using the term for package and shell expressions. | 21:18:03 | |
| Just a problem of terminology. Which should definitely be a consideration for the docs though : ) | 21:19:46 | |
| don't the docs call everything derivations? especially the pills | 21:20:13 | |
| 20 Jun 2023 | ||
In reply to @pennae:matrix.eno.space Because everything is a derivation. Using a different word for derivations in Nix code vs derivations in the Nix store would probably be even more confusing. | 01:56:26 | |
| I created this post to solicit feedback on the tutorial series the working group is working on: https://discourse.nixos.org/t/2023-06-19-tutorial-series-call-for-feedback-1/29377 This is part of the new process we're trying out to be more productive and leverage experts in the community since most of us in the working group are beginners. | 02:53:12 | |
| 08:30:53 | ||
| Alex: I disagree. There's a small set of Nix expressions that result in derivations. They all end up calling the built-in `derivation` in the end AFAIK. | 10:33:53 | |
In reply to @toonn:matrix.orgBut almost all Nix code eventually leads to such a derivation. Setting up those derivations is usually the whole purpose of the code. | 10:38:14 | |
| I hope the documentation can be clear and helpful while still being accurate. | 12:35:14 | |
| nixos-render-docs probably needs a good round of refactoring after the dedocbookifications are done, the current mechanism it uses really doesn't work all that well with what we ended up. markdown-it has a syntax tree module that'd probably be a much better fit to how we handle data. 🤔 | 17:35:20 | |
| 21 Jun 2023 | ||
| pennae: you are working on nixdoc related dedocbookification now right? can you say what would be required for https://github.com/NixOS/nixpkgs/issues/126375 and when it would make sense to do it? I'd be interested to pick it up sometime again, but I figure it doesn't make sense while stuff is in flux | 11:44:46 | |
In reply to @sternenseemann:systemli.orgwould say to wait until the nixpkgs manual is fully converted, which should hopefully be within the next few weeks. we'll try to make the functions doc bit as generic as we reasonably can while we're at it anyway | 12:00:20 | |
| cool ty | 12:29:19 | |
| 22 Jun 2023 | ||
| If we get through updates quickly today, I propose that we look into https://sovereigntechfund.de/en/challenges/ together. We still don't have NixOS and Nixpkgs manual maintainers, and possibly there are other problem domains that could benefit from a large one-time grant. | 06:47:45 | |
| Another fund I've just became aware of https://ostif.org/ | 13:07:09 | |
| sterni: looked into this a bit more, making the function lib docs generic will be a bit more than just a drive-by refactoring. we'll need to extend tooling as well to avoid section id clashes for example | 13:12:21 | |
| it does look totally possible, but not something we can easily fit into the docbook removal process | 13:12:54 | |
| asymmetric: your snapshot tests unknowingly broke pattern argument formatting 😅 | 17:23:57 | |
| Redacted or Malformed Event | 17:43:42 | |
In reply to @pennae:matrix.eno.spaceLol wat, how? 😅 | 17:44:34 | |
| print_indented broke | 17:44:56 | |
| replaced the whole thing with textwrap now, should be much better | 17:45:21 | |
| also for some reason the set of function nixdoc finds is different than when we started, not sure whether the rnix update is the reason or something else | 17:47:39 | |
the rnix update seems to also have lost a number of entries for libraries that use let ...; in { inherit ...; }, sigh | 18:00:22 | |
| the nixdoc approach to finding docs is just ... wrong, really :/ | 18:03:00 | |