2023-08-08 Nixpkgs Architecture Team Meeting #42

Infinisil · August 8, 2023, 3:29pm

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: GitHub - nixpkgs-architecture/pkgs-modules: Working group for using modules for packages
- 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 Package set standardization · Issue #21 · nixpkgs-architecture/issues · GitHub
- 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: Performance benchmark for drv-parts/dream2nix compared to bare derivations · Issue #22 · nixpkgs-architecture/issues · GitHub
- @roberth’s more minimal module system PoC: Simple and quick module system alternative + thoughts and tasks · GitHub
  - 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 [RFC 0022] Minimal module list by edolstra · Pull Request #22 · NixOS/rfcs · GitHub 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 GitHub - nixpkgs-architecture/issues: Repository for tracking problems for the nixpkgs architecture team

Nixpkgs CLI working group search: Nixpkgs CLI Working Group Member Search

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 https://github.com/NixOS/rfcs/pull/137
- @roberth: but not a prerequisite