2023-10-31.md

2023-10-31 Nixpkgs Architecture Team Meeting #45

• 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 NixOS/nixpkgs#256788
  • @roberth: Maybe take a brief look at Junit format for test reports. e.g. first search result: https://github.com/insightsengineering/junit-xml-diff/
    • 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
• NixOS/rfcs#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
    • NixOS/rfcs#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 NixOS/rfcs#163 (comment) and later
• @Ericson2314: Interesting gcc work going on in NixOS/nixpkgs#132343, might be able to get rid of targetPlatform
  • Interacts with bootstrapping
  • Shouldn't be stalled by nobody being willing to merge it