2023-06-19 Documentation team meeting notes #56


  • Review PR #596
  • Review PR #305
  • Discuss Documentation Team meeting structure.


Today we began by reviewing a draft PR about the Learning Journey Working Group’s recommendations for new tutorial contributions:

We then moved on to @olaf’s long-standing PR about expanding documentation on NixOS configuration testing:

Finally, we wrapped up the call with a brief meta-level consideration of the structure of these documentation meetings:

  • @fricklerhandwerk: Changing the way we do docs team meetings; Monday meetings will now be for knowledge-sharing and mob-style PR review if it works for everyone
    • @proofconstruction: We can each take PRs and take notes ahead of time, bring them to the Monday meeting and share, so this process goes faster/we get more work done in each hour we can work together.

I would say its Nixpkgs

I don’t understand why it should be added to the linked example. Can you explain @Infinisil ?

That answer should go right the best practices page, accompanied with a significant issue for the Nixpkgs Architecture Team.

I didn’t expand on this in the notes (I was getting a bit distracted making coffee at this point in the call :sweat_smile:), but I recall the discussion being about acceptable/inescapable indeterminacy using the system-wide nixpkgs and config. @Infinisil wrote something like this

pkgs = import nixpkgs {config = {}; overlays = [];};

but I guess it was decided not to add this as a comment to the PR.

Yes I think I agree. I was paraphrasing @j-k originally, discussion was moving very fast here. Corrected the OP.

Yeah, if config and overlays isn’t passed like that, it defaults to files in ~/.config/nixpkgs and environment variables, which can lead to the examples not working, and is bad practice imo.

We should consider adding a warning when you import Nixpkgs without passing these arguments in the future.

(Yes I know that pure mode doesn’t give you access to those files, but pure mode isn’t the default and not practically usable in stable Nix)


Which I think is not even stable Nix’s fault, but due to the fact that Nixpkgs and NixOS, and all third-party tooling that was created before 2020, is littered with <nixpkgs> and other impure expressions.