2023-10-31 Nixpkgs Architecture Team Meeting #45

Infinisil · October 31, 2023, 6:01pm

Past meeting notes
Matrix announcement
Lead by: @infinisil
Meeting notes by: @infinisil
Present members: @phaer @infinisil @roberth @Ericson2314

Agenda

RFC 140
- Not much to discuss, working on A strategy for evolving the `pkgs/by-name` CI checks · Issue #256788 · NixOS/nixpkgs · GitHub
- @roberth: Maybe take a brief look at Junit format for test reports. e.g. first search result: GitHub - insightsengineering/junit-xml-diff: Tool for comparing JUnit XML reports
  - The JUnit XML format is an industry standard. I don’t know about a JSON successor, but that probably won’t have as broad industry support fwiw (but should)
Moving the team to the NixOS organisation
- At Nixcon spoke with @zimbatm
  - @NixOS/nixpkgs-architecture-team might sound authorized
    - Agreement that it’s fine, shouldn’t be a big problem
  - Could also have a separate new Nixpkgs team comprised of the most active Nixpkgs contributors
    - @roberth: Would go into more all-day stuff, rather than architecture
- Consider using the same issue repo with a nixpkgs architecture label
  - Put this on the future TODO
https://github.com/NixOS/rfcs/pull/146
- Summary: Good to have a categorisation, but not sure how to do it exactly
- @infinisil is worried about it becoming unmaintainable
- @infinisil: Maybe have a solution where we send emails to package maintainer to decide whether new categories apply
- @roberth: Might be too spammy, what about AI
- @infinisil: Might require e.g. at least 30 packages to justify adding a new category
- @infinisil: People maintaining categories becomes unsustainable
- Please participate in the RFC, relevant for Nixpkgs architecture
  - @roberth: On the edge of what is relevant for the team, because it’s mostly data
- @Ericson2314: Maybe just a whitelist of categories
- @roberth: Might manage itself, people add categories when relevant
- @phaer: Is a text search not good enough?
- @roberth: Do we want to embed external categorisations? E.g. the Haskell one
- @infinisil: Actually categorisation is not a problem right now, in the NAT we want to clean up Nixpkgs, so not very relevant
  - @infinisil: Could become a new bikeshedding problem if a “poor” solution is picked, at least monitor the RFC
- @roberth: RDF might be somewhat relevant, because it kind of avoids the philosophical intractability of taxonomies (bikeshedding)
- @roberth: Generally solutions diverge (experiments) then converge (decisions, cleanups), but this RFC is still on the diverging side. The team should mainly be concerned with converging
  - Diverging into new solutions for structural problems where we don’t have any satisfactory solution yet, e.g. package modules, although that could be considered convergence when considering the broader ecosystem
Module system builtin for Nix?
- @Ericson2314: Dangerous, should explore it more first
- @roberth: Tried refactoring of module system at nix.camp exploratory PR
  - can decompose submodule, but need better optionType interface
- @Ericson2314: Should push services not being singletons but support multiple instances
  - https://github.com/NixOS/rfcs/pull/163 goes in that direction, but not module system based yet
- @infinisil: Let’s write more guides and CI to help, instead of migrating modules
  - @roberth: RFC 42 is a good example
- Some amount of showing how it’s done is necessary
- @roberth: There’s a different pattern that could work better, should be explored, see [RFC 163] Portable Service Layer by svanderburg · Pull Request #163 · NixOS/rfcs · GitHub and later
@Ericson2314: Interesting gcc work going on in https://github.com/NixOS/nixpkgs/pull/132343, might be able to get rid of targetPlatform
- Interacts with bootstrapping
- Shouldn’t be stalled by nobody being willing to merge it