- Video conference
- GitHub project board
- Team details
- Past meeting notes
- Attendees: @fricklerhandwerk @infinisil @proofconstruction @henrik-ch @roberth @zmitchell @mightyiam @pennae @alejandrosame
- Notes by: @infinisil
Agenda
- updates
- module system walkthrough
Notes
Updates
- @henrik-ch: Working on reviewing Raspberry Pi Tutorial and documentation survey
- @fricklerhandwerk: Have some work that can be taken apart and put into PRs, will note this down somewhere
- @roberth: Writing about things coming up in Nixpkgs reviews, not much to share right now
-
@zmitchell:
- Learning journey WG wrapping up the first 4-week cycle, having a clear focus each week works well.
- Will post the next call-for-feedback on tutorials soon.
- Summary of Diataxis for nix.dev: Add a summary of the Diataxis framework by zmitchell · Pull Request #634 · NixOS/nix.dev · GitHub, might need some adjustments from the original framework, not user-facing → not a lot of nitpicking needed
- @proofconstruction: It’s important to use this to coordinate our understandings, since we’re not always (often not) on the same page re: what’s a tutorial, what’s a guide, where the line is if anywhere
- Discussed @proofconstruction’s C/C++ tutorial
- @mightyiam: Working on web-devmode PR, could use some help to get it working on Darwin. Got feedback from @pennae
-
@proofconstruction: Working on Raspberry Pi documentation updates, some problems with nixos-hardware modules. Working with @henrik-ch. Works now, but removed graphical support (which most people don’t use anyways).
- More generally, what to do if something we recommend is broken?
-
@fricklerhandwerk: Be clear about it, say that it doesn’t work, link to hints, encourage PRs. Don’t bother fixing it ourselves
- Here are rough notes on how to handle such a situation: https://nix.dev/contributing/writing-a-tutorial#tutorial
- @proofconstruction: There was a note for a nix.dev tutorial that it was probably broken, not a great experience
-
@proofconstruction: This tutorial has a recommendation for verbatim configuration.nix that we promote. Updating it requires copying it into gist, tinyurl, copy back
- @infinisil: Inline into an expanding section?
- @proofconstruction: With a URL it’s easy to curl it
- @infinisil: Inline the file somehow into the markdown
- @proofconstruction: Requires some extra markdown extensions
- @roberth: We shouldn’t have to include big files
- @fricklerhandwerk: Makes sense in that tutorial
- @roberth: Should be made simpler, reduce it to only a couple lines
- @fricklerhandwerk: Let’s not spend too much time on Raspberry Pi work
- @infinisil: I think it’s fine as it is, could be improved, but better than not working
-
@mightyiam: Why would Raspberry Pi instructions not be in the NixOS manual?
- @proofconstruction: A bit complicated, can’t work by default. I’m in favor of moving this there, but we’d need to discuss that separately.
-
@alejandrosame:
- Can we make draft issues?
- Only draft pull requests
- @zmitchell: Create issue, edit it later
- @roberth: Labels?
- @alejandrosame: Can work in private repo then copy as a workaround
- Strategies of better conveying what we do? How to give other people context on what we do? Requires effort but maybe worth it because more people can get involved. Getting pushback from people sometimes
- @fricklerhandwerk: Can’t get rid of this problem in principle. Load should be on contributors, because maintainers are constrained on time. Spend a bit more time to explain context. Make it reviewable at a glance.
- @infinisil: I recommend linking to as many things as relevant
- @fricklerhandwerk: Stop opening new own PR’s, focus on getting your old ones done. It’s hard, but the burden should be on contributors
- Can we make draft issues?
-
@infinisil: Started writing file structure documentation for Nixpkgs in https://github.com/NixOS/nixpkgs/pull/237439, considering taking ownership of the general structure of the Nixpkgs manual
- @fricklerhandwerk: Let’s review this together on Monday
Module system dive by @roberth
-
@fricklerhandwerk: Generic code to evaluate options, part of
lib, used for NixOS, home-manager, nix-darwin, etc. Let’s try to understand the core of it -
@roberth: Module system evaluation is a fixed-point, so there’s no clear start or end
-
What is a fixed-point? Let’s look at the WIP documentation for it in lib.fix: Improve doc by roberth · Pull Request #242318 · NixOS/nixpkgs · GitHub
-
@fricklerhandwerk: A particular value
xfor a functionfsuch thatf x = x - @roberth: Recursion, but factoring out the recursion into a function
- Laziness makes it work, e.g. allowing attributes from
xto depend on other attributes - The result of
fix fis the fixed-point off, same as the result from above,x
-
@fricklerhandwerk: A particular value
-
evalModules plays the point of
fix, but instead of just tying the know of a single function, it can tie it on multiple, themodulesfunctions -
The outcome of the module system is a nested attribute set data structure. The module system takes care of enforcing the shape of that attribute set, and the rules for how to merge them.
-
Validation and merging
-
Allows for aspect-oriented programming: Idea to have a program that hooks into another program, every option is like a hook that modules can use, makes it composable
-
The module system doesn’t care where modules come from, but for specific use cases like NixOS, the user modules (
configuration.nix), get combined with the base modules provided by NixOS -
The module system doesn’t have a “default config”, but options can have defaults (these are just definitions with a lower priority though)
-
- I recommend watching Nix Hour #19, where I build up a very simple module system
- I also recommend going through the commit history (in chronological order) here, where every commit shows a practical example of another module system feature being used
-
Team discussion about structure of the module system and evaluation behavior