2023-03-06 Nixpkgs Architecture Team Meeting #31


Shepherds for RFC 140

  • @roberth as a potential shepherd, but time contraints, pass for now in favor of external participation?

Clean attributes

Module system for packages

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

Thanks for your work and the report!


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 :wink: )

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.

Hosted by Flying Circus.