Skip to content
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.

Latest commit

 

History

History
71 lines (52 loc) · 3.49 KB

2022-09-07.md

File metadata and controls

71 lines (52 loc) · 3.49 KB

Nixpkgs Architecture Team Meeting #9

The following sections describe the agenda of the meeting and also serve as a place to put the corresponding meeting notes. After the meeting, these notes are moved to https://github.com/nixpkgs-architecture/meetings. This HedgeDoc link will be reused for all subsequent meetings.

Protocol

Administration

  • New meeting time

Standup

Agenda

  1. RFC Draft a. Prefix Sharding (Performance vs GitHub display) b. git status faster with smaller dir. Measure? c.

  2. Topologically sorted phase a. why? b. @mkaito : developing an advanced builder with internal closures c. interesting, but unclear how to leverage or to understand desired outcome

  3. Node Modules builder a. Goal? b. Renaming c. [@DavHau]: d2n does not produce renaming for consumption elsewhere

  4. Meeting Times a. move to 2 hours earlier

  5. improve Go build ecosystem a. Have language-specific fetchers, but not builders? b. NixOS/rfcs#109 - @John: we are having good discussions on how tooling could be changed, but the problem is not disagreements on the end goal, but the difficulty in changing unfamiliar lang2nix infra at all (if one is apprkaching as a nixpkgs-as-a-whole / architecture maintainer, rather than specific language-infra maintainer). We don't want every language ecosystem to be a "world unto itself" with bespoke idioms not in conversation with other ecosystems.

     - @David: Problem with RFC: Restricts tooling, makes it harder
     - @John: Make tools better, hold ourselves to these standards going forward
    
  6. Future work a. @infinisil: Auto-calling packages draft

After meeting

  • Overlap of needs with https://determinate.systems/posts/introducing-riff

    • shells for ad-hoc building frequently don't want setup hooks geared for mkDerivation. If e.g. one asks for CMake and pkg-config and gets a setup-hook that does some complicated thing, that can be confusing.

    • Likewise, if we are trying to make "stdenv ng" etc. we might want to use those tools with completely separate setup hooks etc.

    • Solution: be disciplined about putting setup hooks in wrappers, keep the base package "vanilla" and don't presume the package is to be used in a downstream stdenv.mkDerivation build.

  • Riff has some lookup tables able the needs of specific Cargo packages.

    • Nice to store those tables outside of Riff so Nixpkgs and lang2nix can benefit.

    • Data vs code: in general good to separte the data (like the lookup table) from logic using data. Lots of lang2nix tools and Nixpkgs could uphold that priniciple better.

  • buildInputs needed for builds vs needed for using only