2023-08-08.md

2023-08-08 Nixpkgs Architecture Team Meeting #42

• Past meeting notes
• (No recording because Jitsi had an error)
• Matrix announcement
• Recorded and lead by: @infinisil
• Meeting notes by: @roberth @infinisil
• Attendees: @infinisil @roberth @phaer @hsjobeki @Thorsten

Agenda/Notes

RFC 140

• Currently blocked on contributing section pr

Packages Modules WG

• Conclusion: https://github.com/nixpkgs-architecture/pkgs-modules#conclusion
  • Merging with the NAT, review new member applications
    • @phaer and @DavHau from the WG applied
    • Will review asynchronously
      • @infinisil will open a private Matrix to discuss applications
  • @DavHau will work on a poc of using drv-parts to Nixpkgs
  • @phaer: not dissatisfied with the wg
  • @infinisil: would like to center the work around the team issue tracker
  • @infinisil: will update the team workflow documentation (github org readme)
• @tomberek wrote https://github.com/nixpkgs-architecture/issues/issues/21
  • leave a comment if you're interested
• @DavHau did a dream2nix performance benchmark: https://github.com/nix-community/dream2nix/tree/main/misc/benchmarks
  • More test cases would be good
  • Optionally importing modules could improve it - minimizing the number of options to the actually used options (no cmake etc)
  • Let's track this in an issue: https://github.com/nixpkgs-architecture/issues/issues/22
  • @roberth's more minimal module system PoC: https://gist.github.com/roberth/940dff88ca5f5f95949dc309dbe60a65
    • Wrote it to prove a point that a module system isn't too hard and can be faster
    • @phaer: Interested in improvements to more minimal imports
    • See NixOS/rfcs#22 and its linked issues
    • @infinisil: Could be an option to have some declaration of which modules depend on which others, and check that using CI
    • @roberth and @phaer might sync on this
    • @infinisil: Even if you don't have time to work on it, writing down what should be done is already great, please use issues in https://github.com/nixpkgs-architecture/issues

Nixpkgs CLI working group search: https://discourse.nixos.org/t/nixpkgs-cli-working-group-member-search/30517

• 3 people are interested.
• Let's leave it up to the people in the thread to start it

pkg.drvPath string context / DrvDeep

Inquiry by @roberth. Nix team proposes to change the semantics of .drvPath not in Nix but in Nixpkgs. Nix team believes it is a strange behavior and should be changed as far as users are concerned.

Current semantics:

• String context of drvPath contains the .drv file and referenced .drv files transitively and the outputs and the outputs of all build dependencies transitively. Proposed semantics:
• String context of drvPath contains the .drv file and referenced .drv files transitively.

We can not change this in Nix builtins.derivation{,Strict} because that would break old expressions. Hence the proposal to use the Nixpkgs pin to make the change.

Proposed change in Nixpkgs:

• Change mkDerivation to apply builtins.unsafeDiscardOutputDependency, which is not unsafe but applies exactly the proposed change in semantics.
  • For input-addressed derivations it is possible to extract output paths without context, but we believe this does not defy anyone's expectations.
• Check usages of .drvPath in Nixpkgs itself

Impact mitigations:

• Allow users to revert their pin of Nixpkgs while they track down the effect of the change. (grep -F .drvPath, nix-diff?)
  • We expect most usages to be in "advanced functions" which we expect to be comparatively rare outside nixpkgs.
• Add builtins.addDrvOutputDependencies to recover the old semantics where users need it.

Discussion

• @infinisil: This could break user tooling, and it won't emit a warning
• @infinisil: If they reference a .drv they probably would've already stripped the output deps anyway
• @infinisil: How about drvPath2? For the migration
  • Deprecate drvPath and refer users to new attr
• @roberth drvFile?
• @infinisil: nix-build, nix repl use drvPath though, so it's hard to deprecate
• @roberth: Can deprecate drvPath when Nix relies on outputs etc only
• @infinisil: That's the proper way to make this change
• @infinisil: drvPath is a Nix feature, used by Nix, changing the behavior in Nixpkgs has the same effects as changing it in Nix itself, needs to be properly deprecated in Nix itself
• Relates to NixOS/rfcs#137
  • @roberth: but not a prerequisite