The 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 week (currently 13:30 to 14:00 UTC) in Jitsi Meet, open for anybody to join, recorded and live-streamed to YouTube, meeting notes are public.
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.
Agenda
- (@roberth): Start of a design wiki for nixpkgs, where we can organize the knowledge from the meetings. Discussion points from here:
- Extend the scope of the team to maintain a knowledge base about the potential design of Nixpkgs in a wiki
- Delineate what should go into the wiki as opposed to what should be in separate discussions and in official docs
- (@mkaito): Only rely on meetings for hard decisions where the entire team needs to be there (on Matrix)
- (@abathur): Provide more config/util(/maintenance?) functionality by functions in a package’s passthru (on Discourse)
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.
4 Likes
Meeting Notes
Agenda
Design wiki
@roberth Start of a design wiki for nixpkgs, where we can organize the knowledge from the meetings. Discussion points from here:
-
Extend the scope of the team to maintain a knowledge base about the potential design of Nixpkgs in a wiki
-
Delineate what should go into the wiki as opposed to what should be in separate discussions and in official docs
-
@infinisil went over the rest of that thread so far
-
@Ericson2314: Re to valentin’s comment’s: Anything that’s done would also be documented in the usual places, so not a problem. But also a bit skeptical of the benefit
-
@infinisil mentions it is a place to refer people when the same tangent show up again and again.
-
@Ericson2314: That makes a lot of sense! Like a fandom “lore wiki” in a way
Hard decisions for meetings
@mkaito Only rely on meetings for hard decisions where the entire team needs to be there (on Matrix)
-
@infinisil: Good to see everyone, build report, etc. So benefits of meetings beyond decision making or non-personal information exchange.
-
@roberth: Sees both sides, meetings have been unproductive in the past, for now wants to keep every week.
-
@Ericson2314: Agrees with @infinisil, have had some messy meetings, but the community needs more venues, might get rambling because we new to this and have a “backlog” of things to talk about, but the more things we do together, the more structure evolves, improving workings over time
More functionality in packages passthru
@abathur Provide more config/util(/maintenance?) functionality by functions in a package’s passthru (on Discourse)
-
@growpotkin: For complex modules, which we could use for packages instead, it’s sometimes useful yes. But top-level functions are also sometimes the right thing.
-
@growpotkin was loking at POP a bit
-
YANTS yet another Nix typechekcing, a TVL project
Post-agenda
Providing runtime deps impurely after building
-
@growpotkin: had used patchelf for providing runtime deps after the fact
-
@infinisil: coversation might have been about something else:
- try to avoid runtime-only dep being compiled-in somehow
- change openSSL version or similar
-
@growpotkin: to even run the test suite for libtool he had to do some of that
-
@infinisil: pivot-notes.md · GitHub
-
@Ericson2314: Think we can do this more purely
- old goal: security rebuildings are not mass rebuilds
- old idea: Runtime-only dependencies · Issue #1080 · NixOS/nix · GitHub, but don’t think we need that anymore
- Instead of building against .so’s, build against symbol files instead (see also TAPI file)
- Only at link time decide on explicit libraries to link against
- Use symbol files with headers
- CA derivations helps a lot
-
@growpotkin agrees, much easier for “complexity” and “crowd control”
-
@growpotkin: there are some quirks, C++ especially
3 Likes