Als Antwort auf @fricklerhandwerk:matrix.org
This looks great. Still, as @roberth suggested elsewhere recently, we should not encourage using builtins to keep separation of concerns. I suggest rendering what you have to the Nixpkgs manual. It would also avoid getting into hairy consistency problems between Nix and Nixpkgs documentation. The nix.dev reference section should ideally consist only of links to the manuals, but some things are currently hard to do in an ideal way.

Oh, an update on me learning nix stuff and just some introspection: Since the manual is better than the wiki, the wiki is more of a hindrance than an advantage because it's outdated. I'd honestly prefer the manual to be the default result when i google something (but that needs some cute SEO).

(jade): it sucks that our manual is incredibly anti seo because the fact that it's one massive page is incredibly nice to ctrl f and not have to trust some terrible in-page search engine. but the upgrade ryantm is doing would help here i think.

The manual is a nice resource for certain things especially initial setup, but there's a lack of (readily accessible) resources to do customisations like adding nvim plugins, etc. I understand that it's just adding config files like normal distros now.. But that brings up a suggestion of being more clear about the NixOS philosophy. I get that it's highly reproducible, but what exactly is reproducible. What are the things I should aim to replicate with my configurations (is it just my packages and development environments?, or does it also include my shell and text editor configuration? Are my flatpak apps supposed be included in this reproducible build for best practices? how am i supposed to even go about doing this?). While I get that it's honestly up to you, I would highly prefer a guide on how to set up my OS with best practices or really avoid bad practices like nix-env -i

Also the obvious thing remains obvious in terms of documentation missing really explaining what a flake is? I got it at the end, but wow it took me a while. The communication of flakes seems like it's to a systems expert rather than someone who has intermediate or novice skills with sysmgmt.

(jade): especially it's hard to find it in the nix manual and we're doing no favours by having our manuals all separated so that you can't search in one to find things in the other. global search across nix.dev, nix, nixpkgs, and nixos docs would be good maybe?

But also the community is really good like I found this really useful guide which I don't know if you already know which does a good job imo: https://nixos-and-flakes.thiscute.world/ (it's not perfect, but does a good job nonetheless)

In reply to @ryantm:matrix.org
I'm planning to merge this in one week unless I get feedback about it. https://github.com/NixOS/nixpkgs/pull/108063/files it's a fairly self contained change.

In reply to @ckie:ckie.dev
hey so the docs for fixed-output derivations don't have any direct mention of the fact they enable network access? only implications with the fetchurl example?

If you need some guidance to make the change, check this new page: https://nixos.org/manual/nix/unstable/contributing/documentation

It likely won’t cover everything you need, and I’d be happy about feedback on how to improve it

In reply to @alejandrosame:matrix.org
Is the team aware of this PR: https://github.com/NixOS/nixpkgs/pull/108063?

In reply to @alejandrosame:matrix.org
Is the team aware of this PR: https://github.com/NixOS/nixpkgs/pull/108063?

In reply to @asymmetric:matrix.dapp.org.uk
is there a reason why for the module system, we say "defining an option" instead of "setting an option"? I feel like i have to think a couple seconds every time i read definition/declaration, to remember what each means. this wouldn't happen with setting/declaration

Robert Hensing (roberth) wrote a proposal on changing that: https://github.com/NixOS/nixpkgs/issues/185234

I think it should be implemented as written. There's a pile of issues on module system docs, this is one of it.

In reply to @asymmetric:matrix.dapp.org.uk
is there a reason why for the module system, we say "defining an option" instead of "setting an option"? I feel like i have to think a couple seconds every time i read definition/declaration, to remember what each means. this wouldn't happen with setting/declaration

Robert Hensing (roberth) wrote a proposal on changing that: https://github.com/NixOS/nixpkgs/issues/185234

I think it should be implemented as written. There's a pile of issues with the module system docs, this is one of it.