2023-02-13 Nixpkgs Architecture Team Meeting #29

Development Nixpkgs Architecture
1

Notes

pkg-fun.nix vs. other names

  • Going over alternatives from the RFC thread.

  • @infinisil: likes package.nix the best.

    • concurs:

    • @tomberek has small quibble

      • thing with arguments of dependencies is a more general pattern that does work with callPackage

    • @Ericson2314, @roberth, @infinsil: That is is very true, but perhaps as we purposely restricting the scope of the first version of units, this is OK.

      • e.g. if/when units were moved out of /pkg to the top level, that would be a good time to reconsider.

    • @tomberek the default.nix being used today does show continuity

    • @Ericson2314: In fairness to that, the problem with default’s behavior is the CLI, the importing part is fine. The new CLI could just not have this problem.

    • @roberth: but default is a still a bad name, and callPackage semantics and auto-call semantics is not the same.

    • @tomberek: package.nix is Hungarian notation - Wikipedia

    • @infinisil: Good for beginnners just learning the things.

    • @Ericson2314: callPackage could special-case package.nix. Or a callUnitPackage that enforces this an any other invariants we want.

      • @infinisil:
        callUnitRoot ./pkgs/unit -> {
  packages = ...;
  modules = ...;
}

    • Consensus: package.nix is good!

Split into two implementation PR’s

Have a first nixpkgs PR that introduces the mechanism and tries it out on a couple packages, let people try it out, have Hydra build it, etc. This way we can iron out bugs.

After all problems are confirmed to be fixed, another PR for the treewide change is merged.

Consensus:

7 Likes
2

This should be done as close as possible to a new NixOS release. Otherwise we’ll have to do manual backports for up to 7 months %)

3

I looked into that just now, see this comment