Nix Documentation | 412 Members | |
| Discussion about documentation improvements around the Nix ecosystem | 85 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Mar 2024 | ||
| I appreciate any insights you have that would make search and redirection much easier, because the way I see, it would take quite some effort to write yet more custom code to make those work | 11:36:39 | |
| it would not, because nrd already has the option to load javascript files and the nixos manual has demonstrated that such a global script can be used to redirect old links | 11:37:41 | |
| * it would not, because nrd already has the option to load javascript files and the | 11:37:59 | |
| and, to be perfectly clear, we have no objection to doing something cursed like rejiggering the nrd html exporter to build something mdbook could read for structure. but the exporter as exists now must also stay because pulling mdbook into the nixos manual build has since time immemorial been a Not Happening situation | 11:39:34 | |
| From my perspective, the overhead of maintaining custom tooling for everything is on the long run higher than the effort to migrate to a more well-known framework + custom plugins to solve specific needs. We have 0 nrd documentation and resources to let people get started, learn and extend it, and we require people who are familiar with a lot of concepts for them to start making any changes there. With a more well-known framework, we'd have lots more resources that many people without deeper technical knowledge would be able to help | 11:41:08 | |
| as we said. consider the opportunity cost of a team already strapped for resources. | 11:43:37 | |
| but it seems that this is a foregone conclusion, so. | 11:43:58 | |
| That's exactly what I'm considering when I look at the long term of both scenarios | 11:44:11 | |
| In any case, we don't even know yet how much work it would be to make any more well-known framework fit our needs - that's what I'm researching. If we find something that makes things easier in the long run, I'm definitely interested in putting the effort to migrate, but that's an if that we won't know until I finish looking at them | 11:45:21 | |
| I'm positive that it won't be hard to extend some well-known framework to our needs, but that could not be the case. I thought mdBook would be a good one and have been disappointed so far 🥲 there are a few other promising ones though | 11:46:40 | |
| in that case, may there be great success for your research. | 11:47:42 | |
| 11:47:53 | ||
| Yes, to make it explicit: for the long term we have to weigh the cost of onboarding contributors to the infrastructure against the cost of adapting it to our evolving needs at given time. And costs on the contributors’ end are very hard to estimate, so usually all we’re left with is what we know about people who are currently there. That’s another issue with contributor churn: it’s very hard to even assess the trade-offs between evolving existing code and writing new code, because existing code can seem harder to grok than using a ready-made interface, and just as well can get trivial to grok with guidance. | 11:56:50 | |
| * Yes, to make it explicit: for the long term we have to weigh the cost of onboarding contributors to the infrastructure against the cost of adapting it to our evolving needs at any given time. And costs on the contributors’ end are very hard to estimate, so usually all we’re left with is what we know about people who are currently there. That’s another issue with contributor churn: it’s very hard to even assess the trade-offs between evolving existing code and writing new code, because existing code can seem harder to grok than using a ready-made interface, and just as well can get trivial to grok with guidance. | 11:57:13 | |
| I just want to make a note that the new tech stack for the website has already created a staggering amount of regressions, I hope that the panic of regressions on the documentation stack will be unfounded. | 16:34:05 | |
| 9 Mar 2024 | ||
In reply to @raitobezarius:matrix.orgYou mean the nixos.org homepage's move to astro+tailwind? What regressions have you noticed? | 06:59:59 | |
| 10 Mar 2024 | ||
| 04:09:32 | ||
| How can one integrate more of the manuals and documentation directly with Nix? Like if Nix could handle a greater share of the workload, maintaining the website might become simpler. Meaning if it can package anything can it package a website manual in a way? | 04:19:30 | |
In reply to @stablejoy:matrix.org It is in principle possible to write a static site generator in the Nix language, if that's what you mean. It has been done at least once. Whether that will make anything simpler to maintain is a matter of implementation quality and maturity of language tooling. The practical question is always "who's gonna do it". And as @pennae said, we already have something that works. Someone just has to dig into it and make things happen. | 09:07:08 | |
| Refer to the GitHub issues that samueldr opened | 09:55:36 | |
In reply to @stablejoy:matrix.org https://cs.tvl.fyi/depot/-/blob/users/sterni/nix/html/README.md A dsl (by sterni for directly rendering html from nix code, of course this has major performance issues and i you'd be crazy to use it productively but its certainly an interesting experiement. | 10:33:03 | |
| Also this: https://github.com/static-nix/styx | 10:33:58 | |
In reply to @johannes.kirschbauer:scs.ems.hostOMG it's beautiful! | 10:34:31 | |
In reply to @fricklerhandwerk:matrix.orgIt even renders its own documentation. I'd still recommend against it, because it follows the same paradigm as any other static site generator. | 10:36:26 | |
In reply to @fricklerhandwerk:matrix.org* It even renders its own documentation. I'd still recommend against it, because it follows the same paradigm as any other static site generator. You won't gain much. | 10:36:43 | |
| * It even renders its own documentation: https://styx-static.github.io/styx-site/documentation/ I'd still recommend against it, because it follows the same paradigm as any other static site generator. You won't gain much. | 10:37:15 | |
| This styx thing looks like a differently styled version of our huge single page manual. My mouse catched fire from scrolling around inside of it^^ | 10:44:35 | |
| Navigation is a bit better because it has the static side bar. Seems really low in terms of interactivity. I know this is not serious. Just exploring what other people do 🌕️ | 10:47:07 | |
In reply to @johannes.kirschbauer:scs.ems.host🙄 Yeah that's merely about some parameter juggling. Apart from that, there always should be single-page rendering, and that's just as much of a valid way for reading documents. I think it's a regression that the Nix manual did not keep the single page as an alternative. The dynamic search sucks, and you effectively need an entire web browser for it to work. | 10:47:14 | |
In reply to @fricklerhandwerk:matrix.orgOh good point. I think i'll add this to danielsidhion's list | 10:48:07 | |