FWIW, what I don't like about this format is that it is incompatible with Git's tree-ish format <rev>:[<n>:]<path>.

See:

• Git Glossary
• Git Revisions

i've been mentioned directly here, not sure why, but anyway: as the docs team, do we have anything to say in this regard? Or can I go ahead and say "No blockers from the doc team"?

I think it's a no-brainer but wanted to check with someone else first

two questions:

1. can/should we sync this with the members on github?
2. why are we enableFeatureFreezePing = true?

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.