2022-10-26 Nixpkgs Architecture Team Meeting #15

The Nixpkgs Architecture Team (NAT) is there to solve architectural nixpkgs issues that are too big in scope for any single person to undertake. There are regular 30 minute meetings every Wednesday (currently 13:30 to 14:00 UTC) in Jitsi Meet, open for anybody to join, recorded and live-streamed to YouTube, meeting notes are committed to a repository and added as a reply here.

The agenda for the NAT is generally created from discussions in the past week, mostly on Matrix, but you’re also free and encouraged to suggest additional topics by replying to this thread.

Tentative Agenda

Some items are propagated from last weeks meeting as there was not enough time for all of them.

In-person meeting at Nixcon

An ad-hoc in-person NAT meeting was held last week at Nixcon. Present were @Infinisil, @roberth, @tomberek, @Ericson2314, @j-k, @fricklerhandwerk, @DavHau, though I think there was somebody else too. @tomberek took some notes which he can hopefully share soon. Main takeaways were:

The Nixpkgs Architecture Team is on nixos.org now

In a PR to the nixos.org homepage, a section about the NAT was added to the website: Nixpkgs Architecture Team | Nix & NixOS. Now duplicated on the website, the information is removed from the original team page in another PR.

Problems with RFC 127

RFC 127 is in the FCP now, though @Infinisil is not happy with it as it seems to make deprecations throw errors immediately without warning for a release.

JSON schema for NixOS options

@Profpatsch proposed to have a JSON schema for NixOS options, which would allow them to be written with auto-completion in a JSON file. @DavHau, @nbp, @whentze and @piegames were also involved in the discussion. At Nixcon @Profpatsch hacked on this.

Type-checked wrapped fetchers experiment

@Growpotkin updated his wrapped fetchers draft code, e.g. fetchGit. More details and a usage example can be seen in the readme

Handling argument escaping with setup hooks

Originally discussed with @winter in PR #189539, it’s unclear what the convention should be for passing arguments properly to setup hooks. This was also brought to attention on Matrix. @danielbarter was also interested. @Growpotkin and @winter discussed new NPM tooling following that.

Active RFC drafts

In addition to the agenda, this post can bring attention to the existing RFC drafts of the NAT. Feel free to open issues/PRs in these repositories if you want to bring something to attention relating to that RFC draft. Alternatively feel free to chat on Matrix or reply here on Discourse.

  • Auto-called packages: Make most attribute definitions in pkgs/top-level/all-packages.nix be auto-generated from a single flat (or prefixed) directory instead, where the subdirectory corresponds to the attribute name. The ad-hoc category-based structure of packages will be removed.
3 Likes

Meeting notes

Protocol

Notes

In-person meeting at Nixcon

Meeting notes by @tomberek: https://github.com/nixpkgs-architecture/meetings/blob/cb2ee0df5f86c54bdd0eedd43bf583708270e98e/2022-10-21.md

@infinisil acting as the leader of the team was approved by the present members

growpotkin Ameen would like to join the team

Motivation:

  • Loves Nix so much
  • has used it many years
  • has lots of appreciation for everything that has kept that giant monorepo running

Waiting for application in channel (update: was done later)

The Nixpkgs Architecture Team is on nixos.org now

@Ericson2314: Per Nix Community | Nix & NixOS it looks like we need a logo

Problems with RFC 127

  • @Ericson2314 Shouldn’t change mechanism and policy at the same time

    • Great we have a better way to write these things with RFC
    • No point bogging that down with an orthogonal change about what “deprecation” means
  • @Ericson2314 It may well be that we want a “hard deprecation” that is “off by default” (c.f. unfree is opt-in not opt-out), but can also have “soft deprecation” which is a mere warning.

  • @tomberek: no opinion on this

  • @roberth, don’t want to make drama weighing in too strongly as team

  • @Ericson2314: we can express a “team opinion” while make clear we don’t have any formal veto / they don’t have to listen to us.

  • @roberth: That sounds good

  • @growpotkin: It’s all about the tone!

  • @infinisil: Agrees with this

JSON schema for NixOS options

@Profpatsch proposed to have a JSON schema for NixOS options, which would allow them to be written with auto-completion in a JSON file. @DavHau, @nbp, @whentze and @piegames were also involved in the discussion. At Nixcon @Profpatsch hacked on this.

  • @infinisil: Seems cool, but doesn’t need support from the team

  • @Ericson2314: Did he ask for some sort of assistence?

  • @infinisil: Don’t think so, just wanted us to be aware

  • @Ericson2314: Fair enough. Eventually could lead to interesting questions about what the “interfaces” between the module system and external world should be, but no rush for us to tackling that.

Type-checked wrapped fetchers experiment

  • @infinisil and @aakropotkin free-flowing discussion on this as demo

  • @Ericson2314 worried about creating more runtime type checking systems. Put more pressure on other teams adding types. [@tomberek]: +1

  • @growpotkin actually agrees, do not recommend putting this type checking thing upstream, just done “for his own sanity”

    • Some of the utilities however used to write it might go in lib
  • @infinisil Good to reorganize lib too at some point

  • @growpotkin agrees

Handling argument escaping with setup hooks

  • @Ericson2314: is buildNpmPackage deduplicatd with the new setup hooks? Hard requirement from me

  • @infinisil: points out issue with the setup hook and escaping. Wonders we have a new solution

  • @Ericson2314: Wants us to stick with ugly but already in use solution that makeFlags vs makeFlagsArray uses.

    • Ugly, but good to stick with established conventions
    • structured attrs long term should help, solve this properly
  • @growpotkin: Agrees

    • Trying to “defensively quote” can get confusing, error-prone
    • *Array is ugly but reliable.
1 Like