2023-03-06 Nixpkgs Architecture Team Meeting #31

[Infinisil]

• Past meeting notes
• Recording
• Matrix announcement
• Recorded and lead by: @infinisil
• Meeting notes by: @tomberek
• Present members: @infinisil @roberth @Ericson2314 @growpotkin @tomberek

Notes

Shepherds for RFC 140

• @roberth as a potential shepherd, but time contraints, pass for now in favor of external participation?
  • @infinisil: robert would be the most appropriate
  • @roberth: Yes I’m gonna do it

Clean attributes

• https://github.com/nixos/nixpkgs/pull/217243
• Seperately expose the derivation arguments and the “internals”

Module system for packages

• Work group assembly? (cc @roberth)
  • @growpotkin: I’m in
  • @infinisil: I’m in
  • Let’s invite @DavHau
  • Let’s ask @nbp, relevant is [RFC 0003] SOS: Simple Override Strategy. by nbp · Pull Request #3 · NixOS/rfcs · GitHub
  • SOS, flake-parts, POP, simple-modules, blueprints, callPackage, ad-hoc, floco

Update: @infinisil and @growpotkin and some others paired after the meeting to write down a problem description and discourse announcement in Working group member search: Module system for packages - HedgeDoc

Vendored Rust Cargo.locks:

• https://github.com/NixOS/nixpkgs/pull/217084
• FODs being replaced by more fine-grained FODs
• generally we want to avoid computation
• large increase in distributed Nixpkgs tarball size.
  • increase of 32.6 MiB
  • Nixpkgs repo size
    • git history and other junk ( distributed tarball size ) ~90 MiB ( @tomberek )
    • Working tree ( shallow clone ) ~280 MiB ( @roberth )
• similar to “two-phase” nixpkgs? RFC: https://github.com/NixOS/rfcs/pull/109
• recommendation: Only update the cargoSha256 hashes for now, size increase is too much, should be thought about more.

Should we have a time in the meeting for smaller issues

• @infinisil: Let’s have a 10/15 minute in the beginning?
• team should bring up issues and PRs as appropriate
• @roberth: Have a separate meeting to discuss issues/PR’s from project groups
  • @infinisil: I’d have time for another meeting
  • @tomberek: It’s good to have a dedicated work time
• @roberth: One distracted meeting for smaller issues and monitoring the projects (including RFC 140 and the modules for packages)
  • Separate longer work meetings for each of the projects

[davidak]

Thanks for your work and the report!

[Ma27]

Regarding a module-system for packages: I see that it was mentioned in the references section, but was something like extensible attribute sets considered?

My point may be just partly related to a module-system for packages, but ever since @edolstra talked about extensible attribute sets, I’m wondering if we should turn the module system (or an equivalent mechanism) into a language feature.

I can see at least two benefits here:

• with the implementation being completely in Nix, we could save the overhead of interpreting Nix code to resolve a bunch of modules, I guess this would open up an opportunity to optimize the code in terms of performance and memory usage.
• the error reporting could be way nicer. For instance when I do a --show-trace on an evaluation error now, most of the stack frames are about stuff that’s irrelevant (in my experience, I can be 99.9% sure that my own code and not the module system is at fault in case of an evaluation error )

Of course there are a bunch of downsides to this approach e.g. currently this would have to be implemented in C++ I guess and would be yet another feature in the Nix core, but I still think it’d be something worth considering.