Nixpkgs stdenv team
People
- @RossComputerGuy aka Tristan Ross
- @emily aka Emilazy
- @Ericson2314 aka John Ericson (also on steering committee)
- @philiptaron aka Philip Taron
- @reckenrode aka Randy Eckenrode
- @Artturin
Current status and upcoming projects
The stdenv team is new (Tristan started it a few months ago) and in the process of forming. This status represents how I (@philiptaron) see things and am tracking them in stdenv world.
Completed
- Darwin stdenv rewrite. Thank you @reckenrode and team!
- Complete set of helpers for dealing with Bash arrays. Thank you @tie and @wolfgangwalthier!
- LLVM derivations are made common and split apart, greatly easing updates and cross-version conformity. Thank you Tristan @rosscomputerguy!
In Progress
This is well-defined work that is approaching actual completion across the nixpkgs codebase.
- Complete
__structuredAttrssupport. Mostly driven by @wolfgangwalthier. Thank you! - Improving
fetch{git,GitHub, ...}to increase the expressiveness of those functions with rev vs. tag differentiation. Thank you @Atemu! - Thorough removal of
substituteAllin the nixpkgs codebase. - Improving
pkgs*stacking and toolchain/compiler overriding (#365057)
Paused
This is work that was in progress but has stalled for one reason or another.
- Splitting apart the GCC derivation (as
llvmhas done) . @Ericson2314 and @philiptaron started on this, but it’s gnarly. If completed, it will cut down on rebuilds and makes cross-compilation sane. - Improvements to nixpkgs configuration options to document and regularize those options. Since the PR author has left nixpkgs, this is paused.
In ideation
These ideas are well-defined enough to be “worked on”, but the hill to climb in order for them to be “done” requires serious additional thought. In particular, they may come with tradeoffs too bitter to swallow if pursued to the uttermost.
- Structured logging (
@nix { "action": "msg", "level": "1", "msg": ...}) support in the stdenv, so thatNIX_DEBUGisn’t needed any more. If the various Nix logging functions are directly sent to Nix as structured logging, we suspect there will be big downsides. But re-compiling Nix in order to get logging is also pretty terrible. - Continued progress on clarifying what the stdenv environment is and what guarantees are possible across “releases”.
- Linters and checkers (like
nixpkgs-vet) that assist with in-tree and out-of-tree users to provide diagnostics and migrations for necessary changes.
In formation
These are ideas that are yet to coalesce into something that can be “worked on”.
- Single-derivation fixpoints, like @roberth has a draft for. Single package fixpoint step 2: introduce `mkPackage` by roberth · Pull Request #296769 · NixOS/nixpkgs · GitHub
- Automatic bisection of failures, so we don’t rely on @trofi for that.
Blockers and challenges
- Time and attention. Making changes to move the stdenv in any major direction is difficult. Reviewing and gathering feedback on the impact of changes is necessarily delayed, as any change must go through staging.
- Width of purview. The stdenv undergirds the entire nixpkgs ecosystem.
- Machine time to run staging cycles. It’s usually an hour or more to get a single build through of a change to the stdenv on a powerful machine, and less powerful ones take far longer.
Budget requests
None at this time. Any additional budget towards making staging builds go faster, produce more useful information, and detect and automatically flag and highlight issues will always be appreciated and used.